Wikipedia talk:Requests for comment/Responder role

Nitpicks

@Valereee, RoySmith, Enterprisey, Majavah, Xaosflux, Guy Macon, GeneralNotability, and Paul Carpenter: There's some smaller details to nitpick, some on my mind and others suggested by people I've asked for feedback. Separated from the WP:VPI discussion since I'm trying to not clog that up too much, such that it becomes too lengthy for more people to weigh in.

I know we've tried to limit this to the amount that it becomes palatable enough for people to be willing to give it a shot to go to trial, but some things worth addressing:

• valereee added: for blatant high-frequency vandalism and abuse. Do we need to limit to high frequency? eg, if there's revdel-eligible vandalism going on, obvious abuse, does a holder of this right really need to revert 3 or 4 times before they can block the IP? If yes, what if multiple IPs participating? If they've reverted one IP 4x and blocked, and another IP starts, can they block immediately or do they have to revert them 4x too?
• Just so we're all on the same page, can this group (in the scope of obvious vandalism and abuse) dish out blocks as an admin would've, or can they only deal with very high volume vandals? eg should people with this right, if they were the reverter/Huggler in this case, be blocking [1] after multiple warnings? Or [2], could a person with this group have made this block? Or this, this or this? Or does it have to be more like this? My understanding was yes, their remit is to stop vandalism, even if it's not at a rate of multiple per minute but instead one every five.
• YConcern raised: Can users with this right reblock if no response at AIV and vandalism continues after unblock expires? If yes, how long do they have to wait (or immediately)?
• YAdjustments during trial: to make the most of a 3 month trial, do we want to shove in some kind of clause that allows admins, by some quick consensus, to make changes during the trial period? Such as imposing extra restrictions, changing how the WP:PERM for this is clerked (eg currently WP:PERM is mostly for admins to discuss, but this process could also be more like EFH with more community participation?)

Personally I think, given that people holding this right are going to be people experienced in anti-vandalism anyway, it's worth treating them as if they can think, and I can't imagine anything going wrong. Still, some ability to do something is better than the status quo of no ability, so if it needs more restrictions to pass then that's the cost, I suppose. ProcrastinatingReader (talk) 19:48, 11 December 2020 (UTC)

I'm not married to high-frequency, but I did see it as something that would deal with situations like the one that started the discussion: something that is requiring an editor to revert over and over while they wait for help to arrive. How often were you thinking the tool would be used? I do agree that as the proposal is set up, we are likely to have cautious use. I'd assumed experienced anti-vandalism workers would be quite likely to hope they seldom run into a reason to use this. I would say if the edits don't justify a 3RR vandalism exemption, they don't justify this. Open to arguments. —valereee (talk) 20:51, 11 December 2020 (UTC)

Glad I brought it up! See the various contribs links I posted. We all agree that the ones such as that in the "Background" section is a valid case, I think. How about the various diffs/contribs I linked? Are any of those cases acceptable (if so, which)? Another case: if AIV is backlogged and no admins have been around for a couple hours, and some of the reprted (by others) vandals are still active (perhaps not rapid, but say every 10 mins), are users of this group free to block temporarily? I think these are examples where we want to draw a line to avoid misunderstanding. ProcrastinatingReader (talk) 21:01, 11 December 2020 (UTC)

3 different points to consider:

A small clarification - the minimum amount of support to assign this permission as written is 4 people, a (potentially non-admin) nominator, 2 admins supporting, and an admin closing, right? I saw at VPI suggestions that it was 3.

There should be a circuitbreaker to prevent someone from running away with this permission or using it too fast. Something like a limit of 5 concurrent blocks, or a 5 minute cooldown on the ability to block, or something like that - many ways to skin the cat.

People are going to refer to the Law of the instrument in opposition to this. If the only tool that someone has to deal with an article is blocking, they will use it even if semi-protection is a better tool. For example, if TMZ reports that some celebrity died, I could see a flood of IPs to report the unconfirmed news. The appropriate response would be a temp semi-protection, but someone with this tool can only sit on their hands and wait for a full admin, or break policy and start playing whack-a-mole. Tazerdadog (talk) 03:43, 16 December 2020 (UTC)

I guess it technically becomes 4. I don't think this is necessarily a problem - many have raised the concern of this tool being too easy to get. A minimum of 3 admin eyes seems okay.

Regarding law of the instrument, I think people with this tool would be okay with sitting back. The kinds of people I have in my mind with this tool I don't think would start playing whack-a-mole, but obviously that'd be a reason to pull the right, and since all blocks would be reported to AIV for admin review it wouldn't slip past anyone's eyes. ProcrastinatingReader (talk) 20:07, 19 December 2020 (UTC)

Moving to a proposal and Technical

Split from above section for neatness/organisation. ProcrastinatingReader (talk) 22:24, 11 December 2020 (UTC)

@ProcrastinatingReader: (not a complaint) but as you've noticed that VPI has gotten a bit wide; to move past VPI in to a proposal something specific and actionable should be ready to propose; specific as in "here is my ideal framework for this thing" and actionable as in - this is something that could actually be implemented in short order if it is accepted (so for example something that would require a developer to create a new extension and then have that extension approved for the project would not be as useful; also any of the "bot" type ideas: unless there is an actual bot operator ready to say "I have written this bot and will manage it" -- it won't be as useful). Reason being, you usually don't get a lot of opportunities to present the same thing and if its not actionable it will likely get tabled, but then if it is ready too soon other may get tired of discussing it. If your solution is along the lines of "Create a new usergroup containing the following (existing) permissions. This is the policy about this group's use.", then great - start drafting that on to a page (WP:PMVR is a fairly solid and more recent framework that you could model upon). — xaosflux ^Talk 20:00, 11 December 2020 (UTC)

Even on another read of User:ProcrastinatingReader/draft, this doesn't really yet say how any of this will be implemented - and approving vaporware leads to nothing being delivered (see the should be (performed)... using coding magic... from WP:ACERFC this year:) if the proposal relies on future magic and no one discovers a magic coding wand it dies out. — xaosflux ^Talk 20:04, 11 December 2020 (UTC)

@Xaosflux: for actionable I so far have thought of three technical routes of achieving this. Namely: (1) just give "block" in trial, we then have the 3mo trial to work on 2/3 or just decide block is fine; (2) give granular perms - ie the phab task you linked with the extension, though Martin Urbanec suggested adminbot is more realistic logistically; (3) use a bot (we have multiple technical admins involved here which is neat, and this seems quite easy to make as a bot, so we can likely pull this off too). But in deference to the one step at a time / technical details later suggestion I'd mostly kept this stuff in my local notes.

For specific, I think part of my concern is that the trial is more limited than the right probably should be post-trial, to make it more palatable, so it feels harder to write a full WP:PMVR-style policy (so I based this off WP:TPE). Per question #2 above I'm not sure if we're all on the same page re scope yet. To some degree, I'm concerned too many details may give more points to cause opposition and nitpicking itself, so I'm not yet sure where to strike the balance. Do you think this more 'simplistic' approach may end up working against the proposal?

Sidenote, if necessary, we can also try to break this up into multiple proposals (PMR RfC style) rather than one (TPE RfC style)? Maybe depends how thorough we want to be here? ProcrastinatingReader (talk) 20:26, 11 December 2020 (UTC)

I'm happy to write a bot to do this, but someone else will have to operate it as I'm not an admin. Majavah (talk!) 20:36, 11 December 2020 (UTC)

If someone wants to go "bot" route, I'd suggest that this is done more as a hosted tool than a traditional bot; running on WMF servers using OAUTH for people wanting to trigger the "bot" - either using a group or an on-wiki json page for the list of users; then the tool can enforce some more things before the bot makes the block, using a block reason that indicates the triggering user. I don't really love this idea - but think if we want to go bot, it may be a better solution (and need more discussion about letting the admin that owns the bot allowing such delegation of "their" block access). — xaosflux ^Talk 20:56, 11 December 2020 (UTC)

Maybe I'm overthinking it but if done on a hosted tool doesn't the admin operator have the technical ability to "frame" another editor? Whereas all diffs are logged onsite so this is impossible, a malicious bot operator could presumably say I tried to block User:xaosflux along with 30 good-faith IPs, and I couldn't prove otherwise? Maybe a sysadmin could dig the access logs but eh. ProcrastinatingReader (talk) 21:11, 11 December 2020 (UTC)

We could have the tool make an edit as the user (using OAuth) to a central log page whenever it makes a block. More broadly, I think making a tool is the best option, because accidents happen and I'd rather make misuse impossible instead of just telling people not to do it. Enterprisey (talk!) 00:45, 2 January 2021 (UTC)

This works for me. imo the three main things this proposal currently needs before it goes live:

1. Data, to visualise the problem better, which may convince the community. Time to block metrics, or something, not sure. Do you think you may still be able to get around to that? (I know I'm shoving a lot onto your plate these days :/ ...)
2. Criteria which would indicate that the trial was successful, and actually solved the identified problem.
3. Adjustment to granting criteria. I asked some people privately, a couple raised concerns the perm may be too easy to get and people unqualified get around it, which would lead them to oppose. A new PERM page will not be highly watched, either. Maybe making the nomination process either happen on the WP:AN, or advertised to there, will be one solution around this?

ProcrastinatingReader (talk) 04:23, 2 January 2021 (UTC)

Would you believe me if I said I totally forgot about that... I should really keep a queue of things I'm doing on my user talk page. I'll get working on it real soonish, as you or someone else said there's a sense of momentum about this proposal. If possible, it would also be nice to get your feedback on my idea of only allowing the tool to block users for which each of their edits have been reverted; I feel like that might help a little, although I don't really know. Enterprisey (talk!) 06:31, 2 January 2021 (UTC)

Heh, I think I know the feel. Thanks!

I guess the goal of the idea is to make the proposal more palatable for people? I'm probably the wrong person to know what will make 'unbundling block' palatable to the community. At least from the admins I've talked to privately who didn't quite like this proposal (nb: small sample size), I gathered that the fear was not so much that the people we imagine having this perm not having the common sense to use it properly, but rather the perm falling into the wrong hands. I think that fear is key to address, via the granting process.

A revert restriction in the code of the tool is a good technical limitation in the tool I think, but maybe not requiring all edits to have been reverted (if the IP makes a new edit whilst a user is clicking 'block' in the tool, then the block would error out: "This IP has unreverted edits."). ProcrastinatingReader (talk) 19:42, 2 January 2021 (UTC)

I should note that we should be careful not to go too far in the limitations, also, to the point where the tool can't be used to stop problems. See point #2 above. If, at the end of the 3 months, it turns out this tool had a negligible effect on solving the problem, it will be hard to identify whether that was because we limited this tool too far, or because the idea was crap, and maybe the community won't give us a 2nd chance with more liberal restrictions to test which it was. ProcrastinatingReader (talk) 19:54, 2 January 2021 (UTC)

BTW, if "block" always includes the ability to unblock then option (1) may be DOA. Many people in the 2013 RfC opposed due to giving people the technical ability to undo CU blocks. I mean, I don't personally think the people that would get this perm would actually undo a CU block, but... Also, MusikAnimal also mentioned an extension won't happen, so (2) is seemingly not happening. ProcrastinatingReader (talk) 20:41, 11 December 2020 (UTC)

Admins can undo CU/OS blocks - but they are told by policy that they may not, and if they do they may loose access - same should be able to go for any other group. — xaosflux ^Talk 20:49, 11 December 2020 (UTC)

(edit conflict) @ProcrastinatingReader: As far a "simple" goes, the simplest thing would be to make a new access group, give that group access to (block), define the criteria for the group - and also amend the blocking policy perhaps by adding a section about what these are - perhaps something like "Limited Vandalism Blocks", empowering the members of the group to make the blocks in whatever the appropriate situations are and restricting them to only using the access for this reason. This is simplest from a tech perspective as there is only a trival configuration file update needed - not sure how simple it will be from a community buy-in perspective. — xaosflux ^Talk 20:49, 11 December 2020 (UTC)

I mean, I'm 100% in agreement with you, and it's also my preferred option, plus I don't think there's any greater risk than admins having the technical ability to do it (given the kinds of people that would be in this group). But see opposes here (2013). I'm worried giving "block" may cause concern. Plus, it seems a lot of the same people moved from support to oppose and vice versa from the 2013 RfC to the 2015 one, so a lot can change I guess, and it doesn't help that I have no clue what the community sentiment on this point is atm. ProcrastinatingReader (talk) 20:55, 11 December 2020 (UTC)

• Possible script "aid". Would need to be tested, but if we go with a new group that has block, we may be able to use a group-js that changes the block form to only show them the options they should use. Keep in mind this is not a "control" but could be used to reduce accidentally or mistaken selection of options not otherwise supported by policy. This wouldn't help if using other tools to do the blocking (such as Twinkle or client side programs that use the API). — xaosflux ^Talk 16:30, 14 December 2020 (UTC)
• I've updated the "Implementation" section to specify an AWB-style checkpage, and then a designated page that editors with this permission may edit to request that an adminblock issue a block. More auditable that way. Enterprisey (talk!) 21:29, 2 January 2021 (UTC)
• I'm at least still weakly opposed to this whole plan - I don't like having an entire workflow built around someone's bot. Couldn't this be an extension? — xaosflux ^Talk 00:52, 7 November 2021 (UTC)

  I agree with you that this should be an extension. I would certainly love it if we had an extension author ready to go (and WMF people ready to approve and deploy it), but I'm not aware of any. Enterprisey (talk!) 08:14, 7 November 2021 (UTC)

Strategy

Split from above section for neatness/organisation. ProcrastinatingReader (talk) 22:24, 11 December 2020 (UTC)

More on Strategy:

I would like to emphasize a few things as this gets discussed:

• It will almost certainly be shot down. Most unbundling proposals get shot down. There is very little reason to believe that this one will one of the rare exceptions.
• If it gets shot down it doesn't matter how effective it would have been. A mostly ineffective change that actually passes will get more done than a super effective change that ends up on the failed proposals pile.
• If it passes and the trial goes well we can improve it. If it passes and the trial goes well, it will be a lot easier to get approval for a small change like allowing more actions per day or making the tool easier to obtain.
• We should optimize the proposal so that it avoids predictable opposing arguments. Things like the "do we want to shove in some kind of clause that allows admins, by some quick consensus, to make changes during the trial period?" question above are a good example. We should propose that they can make easily the tool harder to use and harder to abuse but making it easier to use should not be allowed until after the trial.
• If the resulting proposal is ineffective that itself could be used as an argument against it. The obvious counterargument is to keep hammering on us wanting to start slow and that there will be another proposal after the trial expires.

--Guy Macon (talk) 21:54, 11 December 2020 (UTC)

• For an attempt to pass, this should also succinctly state what the problem is, and what the expected improvement from a trial would be. Having a measure is important to judge the success of a trial. — xaosflux ^Talk 23:51, 11 December 2020 (UTC)

  I've went ahead and added bullet #4 and the section below into the proposal.

  Good point! Problem statement could definitely do with some work, and indeed some metrics to determine success at end of trial. Added inline notes where I think that can be added, but people reading (far more eloquent writers than I) should edit away. I think Enterprisey suggested they may collect some data which could come in handy, also User:ProcBot/EW and its page history has a lot of useful case studies where this right would've been useful (some false positives too, and some content disputes, but on the actually problematic pages of vandalism the avg block time is between 20 mins and a couple hours, a couple times upwards, just glancing quickly). ProcrastinatingReader (talk) 00:36, 12 December 2020 (UTC)

  @ProcrastinatingReader: as far as the problem, it sounds like the problem trying to be solved is a few parts (this is a potential recap, not a statement of my opinion):

  1. Vandals continue to disrupt the project
  2. There are insufficient administrators available to stop these vandals in a timely manner
  3. There are insufficient editors willing and/or qualified to become administrators

  With the solution being proposed being empowering certain qualified editors access to block these vandals under certain conditions. — xaosflux ^Talk 03:20, 12 December 2020 (UTC)

  That, and it wastes vandal-fighters' time to be reverting vandals repeatedly (which does sort of follow from that, but I figure is worth stating explicitly). Enterprisey (talk!) 10:20, 12 December 2020 (UTC)

  Thanks! Added something along these lines. Thoughts?

  I've also removed the old discussions (which are useful to refer to for drafting, but in proposal I think it's best we stick to showing the recent discussions). They're in Special:Permalink/993696759 for ref. ProcrastinatingReader (talk) 11:36, 12 December 2020 (UTC)

Phrasing

On a sidenote of strategy, I think it's worth mentioning that how something is presented can make a big difference to acceptance, it seems. For example, consider this proposal. There was no consensus to allow non-admins to "delete" at TfD. But there was consensus to allow admins to orphan and delete (the same thing). Now, non-admins regularly close TfDs as delete. I quote from that RfC: And that is why this is the same proposal as above with a different name. Interesting (mostly off topic) fact about the power of words - "delete and orphan" vs. "orphan and delete" - is that one version gets a majority of opposes and the other a large majority of supports. Human mind is fascinating :-). What is the equivalent of that in this case? For example, perhaps focusing it around people being able to operate a bot seems more acceptable than saying "a user right"? And perhaps we can put some lipstick on the word "block" somehow? ProcrastinatingReader (talk) 12:47, 12 December 2020 (UTC)

"Your editing is being deferred"? "You are asked to temporarily direct your efforts elsewhere"? EEng 17:34, 12 December 2020 (UTC)

Emergency shut off idea

"We need an easy way to stop the thing; implementation details TBD"

Emergency shut off idea: What say we propose that any admin can push a pause button on the three month trial at any time and open a discussion at AN? If the trial gets suspended for a week the end moves so that it is a week later. As I said above, we want to make the proposal as palatable as we possibly can. This might give more admins a good feeling about it. This is similar to and in addition to the current "Revocation" section, except that one appears to be per-user instead of pausing the tool for everybody. --Guy Macon (talk) 21:57, 11 December 2020 (UTC) Guy Macon, Aren't bots already required to have an emergency off switch? And anybody can already start a drama board discussion any time they want. -- RoySmith (talk) 15:22, 13 December 2020 (UTC) This has to do with strategy. I am proposing that we make this proposal more palatable by explicitly inviting admins to shut it off and providing a big red shutoff button. Yes, any admin can block any user -- including bots -- but let's look at User:SineBot; there is no invitation to shut it off and indeed any admin who blocks SineBot had better have a damn good reason. And don't even think about mass-reverting Sinebot unless it has gone crazy. Contrast this with User:Yobot; that one has a big red shutoff button. Saying that such a button will exist and inviting admins to use it might make a few opposes turn to supports. --Guy Macon (talk) 18:52, 13 December 2020 (UTC) I'm with Guy. Absent an emergency, no admin is likely to shut it off, but the fact someone could will help make people feel more comfortable with giving it a try. —valereee (talk) 19:52, 13 December 2020 (UTC) Valereee, Interesting. I thought the Big Red Button was standard for all bots, and that's what I was referring to by Aren't bots already required to have an emergency off switch? Yeah, we need one of those. -- RoySmith (talk) 22:06, 13 December 2020 (UTC) I have been doing a bit more research on this. See Wikipedia:Help desk#Emergency shutoff-compliant?. --Guy Macon (talk) 00:43, 14 December 2020 (UTC) To answer your Q, those buttons are opt-in by the bot operator, and not required by the bot policy. Triggering the button does nothing onwiki automatically. Usually the button links to a page where you change "on" to "off" or similar, and the bot code detects that and turns off. Some botops limit the page to admin/ecp, others let anyone trigger it. As for block, I'm not sure if blocking an admin stops them from blocking other people. In any case, these technical questions are easily remedied by the bot, the easiest way being to sysop protect the bot run page so non-admins can't use it anymore. ProcrastinatingReader (talk) 00:54, 14 December 2020 (UTC) ProcrastinatingReader, I've never run a bot per-se, but do a lot of API work. As far as I know, an admin bot presents auth credentials like any other user, and if that user is blocked, the bot can't do anything. So, the Big Red Button is, "Please Mr. Bot, chill out", and if that doesn't work, you can whack it upside the head by blocking it. -- RoySmith (talk) 01:17, 14 December 2020 (UTC) Except when it isn't. The big red button on Yobot triggers this: https://en.wikipedia.org/w/index.php?title=Special:Block&wpTarget=Yobot&wpExpiry=indefinite&wpHardBlock=1&wpAutoBlock=0&wpCreateAccount=0&wpReason=other&wpReason-other=Bot%20malfunctioning:%20 --Guy Macon (talk) 01:26, 14 December 2020 (UTC) A bit off topic from what we should be discussing, but not only can a blocked admin block other people, they can unblock themselves and block the admin who blocked them. Of course anyone who actually tried that would be desysopped by an arb or a crat within minutes, but the ability to unblock yourself and block the admin who blocked you is an important safeguard against a vandal getting control of an admin account and blocking all the other admins. In 1378 there were three popes who all excommunicated each other, and of course all three said the other excommunications were invalid because the were performed by someone who had been excommunicated.[3] In 1982 Bendix launched a hostile takeover bid of Martin Marietta and Martin Marietta launched a hostile takeover bid of Bendix. For a short period of time Bendix owned a majority of Martin Marietta shares and Martin Marietta owned a majority of Bendix shares. --Guy Macon (talk) 01:26, 14 December 2020 (UTC) Guy Macon, OK, just to get this back on track, let me suggest some specifics. We need a Big Red Button. One that links to Special:Block (as in the Yobot example you gave) would be good enough. -- RoySmith (talk) 03:20, 14 December 2020 (UTC) Well, that’s the thing. Afaik a blocked admin can still block other users, right? So blocking the bot probably won’t stop its task. Still, this is merely a technical detail since the task could be stopped by an implemented kill switch, or by protecting the op page. ProcrastinatingReader (talk) 03:51, 14 December 2020 (UTC) ProcrastinatingReader, I see your point. OK, so we need a Big Red Button that tells the bot to stop itself. -- RoySmith (talk) 14:34, 14 December 2020 (UTC) I think this is going off the rails a bit on the technical parts. FWIW, there are basically 2 "sensitive" things a blocked person can do (if they have the access normally): (1) block the user that blocked them; (2) use their enhanced viewing access such as reading deleted versions. — xaosflux Talk 16:28, 14 December 2020 (UTC) I think you missed the point. Given a bot that blocks IPs for an hour, a big red button that blocks the bot will do nothing to stop it from continuing to block IPs for an hour. You need a big red button that stops the bot from operating. This is an important technical distinction that needs to be in any proposal, otherwise someone will say that the goggles, they do nothing the proposed big red button will do nothing. --Guy Macon (talk) 04:27, 16 December 2020 (UTC) Doesn't blocking the bot stop it from blocking IPs from an hour? AFAIK it can only block the user who blocked it and not others. Majavah (talk!) 08:24, 16 December 2020 (UTC) I think the concern is that any users currently blocked by the bot should be unblocked if the bot gets an emergency shutdown. So the big red button needs to function also as an unblock for any user the bot blocked in the past hour as long as an actual person hasn't come along behind the bot and reblocked. —valereee (talk) 12:52, 16 December 2020 (UTC) Majavah Unless I am mistaken, blocking a user only prevents them from editing (except on their own talk page). No administrative tools (page protection, blocking users. reading certain deleted material, etc.) are affected in any way. Any administrator can block any user (including another administrator) but it takes a Bureaucrat to remove administrative rights. As I understand it, Arbcom can decide to desysop, but the actual removal of administrator right is done by a 'crat. --Guy Macon (talk) 14:49, 16 December 2020 (UTC) Valereee, A simpler solution might be that it keeps a log of every block it makes, with each log entry including an "unblock" link. Then at least if the bot goes rogue, it's relatively easy for a human to clean up. -- RoySmith (talk) 15:03, 16 December 2020 (UTC) PS, or maybe a crat-bot, which could automatically desysop the admin-bot. What could possibly go wrong? -- RoySmith (talk) 15:11, 16 December 2020 (UTC) However, now what if the bot goes rogue and someone needs to strip it of the crat? Crats can't remove crats, so we may need a steward bot to handle that case (some kinda page where a crat can enter {{decrat-the-bot}}) ProcrastinatingReader (talk) 15:14, 16 December 2020 (UTC) *ProcrastinatingReader watches as xaosflux loses hope* How about a system admin bot which can be used to de-steward that stewardbot? Next up a power plug pulling bot to get rid of that sysadmin bot? Majavah (talk!) 15:19, 16 December 2020 (UTC) Stewards can remove stewards so this part is actually quite simple: we just need a 2nd steward bot to keep the first steward bot in check. A bit like the 2 CU requirement to keep the other CU in check. ProcrastinatingReader (talk) 15:20, 16 December 2020 (UTC) But if one of the steward bots malfunctions and is no longer a steward, we need a new one to make sure the existing one is working? This sounds like the job for a stewardbot-making bot. Majavah (talk!) 15:23, 16 December 2020 (UTC) @Guy Macon Blocking does prevent blocking and other admin actions. You can block the user who blocked you; that's the only exception. Just tested. Majavah (talk!) 15:16, 16 December 2020 (UTC) Yup --- follow this back up to the bullet where I noted that already ;) — xaosflux Talk 16:33, 16 December 2020 (UTC)

I had a suggestion to change the 'any admin may stop the trial' language to 'an emerging consensus is grounds to stop the trial' (paraphrase). Thoughts? ProcrastinatingReader (talk) 20:08, 19 December 2020 (UTC)

IMO the harder it is to shut down the greater the chance that the entire proposal will be rejected. Actually I seriously doubt that this will ever see the light of day, but we want to make it as palatable as possible. --Guy Macon (talk) 21:22, 19 December 2020 (UTC)

"Any admin can stop the trial (the bot will undo all current blocks and stop making new ones) but the admin must also open an AN discussion"? Enterprisey (talk!) 21:27, 2 January 2021 (UTC)

Remaining items before going live

1. Y Data, to visualise the problem better, which may convince the community as to the extent of the problem. Time to block metrics or something. (WIP by Enterprisey)
2. Y Criteria which would indicate that the trial was successful, and actually solved the identified problem. [Links in with #1? eg a decrease in time to block metrics]
3. Adjustment to granting criteria. The main concern raised is that this perm may be too easy to get. Adjustments so far to try to address: advertising requests to WP:AN, to ensure wide participation, and a 48h hold for discussion. Anything else we should do?
4. Enterprisey suggested surveying some normal content creators / the average editor, non-admins. I think they'll probably make or break this proposal when it goes live, given it'll probably be advertised on watchlists. Can we do a little straw poll, or ping a selection of folks here, so we can get their thoughts? Content creators (@Valereee and Barkeep49) any ideas how we could do this / who to ping?
5. Y Final thoughts on the name? First responder? Responder? Something else?
6. A copyedit.

Any other items? ProcrastinatingReader (talk) 09:44, 4 January 2021 (UTC)

Re: how to ping normal content creators...that's a tricky one. Many normal content creators don't involve themselves much in policy. But as to where to find a good selection of them, DYK is a good bet. Anyone nominating at DYK who has more than 10K edits is probably primarily a content creator.

Re: final thoughts on the name, my !vote is Responder. First Responder sounds too cool, and for this permission I'm all about not sounding cool. —valereee (talk) 12:02, 4 January 2021 (UTC)

You know my skepticism with this proposal. In terms of a possible straw poll I think the Village Pump is the most policy/guideline compliant way to reach editors and this has obviously been there. Outside of that if you're really trying to reach content creators you could pick a couple of the larger Wikiprojects as a neutral way of gathering some more feedback. Best, Barkeep49 (talk) 16:40, 4 January 2021 (UTC)

Wikipedia:Centralized discussion -- RoySmith (talk) 16:53, 4 January 2021 (UTC)

Re: success criteria, I've just added a few really drafty criteria based on the problem statement. I also agree with valeree on that my vote would be Responder as well both because of the too cool aspect and my personal issue that first responder is too far from the actual userright. Asartea ^{Talk | Contribs} 10:41, 6 January 2021 (UTC)

Range blocks?

Just as a thought experiment, consider Wikipedia:Sockpuppet investigations/Broter. How would this work there? Would we be allowing our First Responders (trademark pending) to enact range blocks? Or would the idea be that they could just react faster to IP hopping than could happen via SPI? -- RoySmith (talk) 18:20, 4 January 2021 (UTC)

The way I’m thinking of it currently is: would granting the ability to range block turn any opposes into supports? Or would it turn any supports into opposes? I feel like the latter is more likely. It’s probably worth proposing later, but even some of page mover’s current rights failed to pass in the original RfC. Since this is all one big proposal, it kinda all passes or all fails, unless we want to break it down into parts somehow. ProcrastinatingReader (talk) 09:16, 5 January 2021 (UTC)

mini-admin

I'd lose the "This is not a "mini-admin" role" statement, because, yeah, that's exactly what it is. If we're going to propose this, we should own it. -- RoySmith (talk) 14:52, 5 January 2021 (UTC)

RoySmith, I think the concern is more being labeled as a "mini-admin" or "mini-mod" role, because that would make it an even more attractive permission for more inexperienced editors to try to get. I agree that that statement should be removed, though—maybe some emphasis on it being a permission with essentially no authority could help? Perryprog (talk) 15:36, 5 January 2021 (UTC)

I've removed it. I wanted to distinguish this from the usual unbundling proposal, but I guess the rest of the text does that just fine. Enterprisey (talk!) 09:23, 6 January 2021 (UTC)

Reading material

With apologies to people who've seen this already, there are a lot of prior discussions at Wikipedia:Unbundling administrators' powers#Failed proposals, especially Wikipedia:Village pump (proposals)/Archive 120#Proposed user right: Vandal fighter, which is very similar indeed; I found them enlightening. Enterprisey (talk!) 09:25, 6 January 2021 (UTC)

Extracting from this I see opposition based on: (bold are problems which are brought up often)

1. Lack of hard data on backlog rates (Enterprisey you're working on this right?)
2. Too loose granting requirements (addressed, current proposal is much harder). This seems to be one of the main pain points however the current proposed community notifications/multiple admins/required time should address this quite well.
3. The old go see RFA argument [note: add info about vandal fighting not equal admin, content creation]
4. Who would get blocked/abuse . An bot/tool which limits the rights should hopefully address these
5. The kit/an admin would need to cleanup afterwards. [note to self/someone: clarify that right is not meant as replacement for AIV but as an support for it]. This is also a pain point, lots of people arguing this would only cause more admin work not less. See earlier counterargument + potential explanation of the north American problem?
6. newbie biting/content dispute enforcement/edit warring. Not really certain what we could change to address this, already quite well covered in policy
7. better unbundle semiprotection than block. potential counterarguments: semi deals more damage, vandals can hop pages etc Asartea ^{Talk | Contribs} 11:14, 6 January 2021 (UTC)

And then there was data

I finished coding and made User:Enterprisey/AIV analysis. I can email the data to anyone who wants it. If anyone has suggestions for how to analyze the data to try and answer the question "should this role exist", that would be nice. I only have a histogram showing how the number of edits reported users make before they get blocked varies, and I think there's room for a lot more. Enterprisey (talk!) 08:43, 16 January 2021 (UTC)

Some interesting tidbits from the data that Enterprisey has shared. We need to visualise these but it looks like the graph template is not great, so might be that they need to be uploaded as images. Which isn't super accessible, but I can't see an alternative.

Period: 00:00 01DEC2020 to 16:27 06DEC2020

• Almost 1/3 (32.47%) of reports take longer than 30 minutes to be worked.
• Total of 850 reverted edits would have been prevented over this period. There are significant dangers with annualising data from such a small sample size, especially over as abnormal a year as 2020, and I think it would also be erroneous to assume that all of these edits would be prevented by this role (as vandals may simply wait until the short block expires and then continues). However as a starting point - annualising this data would be 54,549 edits.

Other areas that I think would be interesting to delve into:

• Ideally, I think we would group 3 edits to the same article that were reverted in one click together. The focus here needs to be on editor effort, not on total edit count. If a vandal makes 10 consecutive edits to the same article I'm not overly interested - but if an editor has to revert them 10 times, I am.
• Outcomes from AIV reports. In particular, how many blocks are issued by admins that actually could be issued through this process, and are there any useful nuggets around stale reports.
• Analysing the type of article, type of revert, or type of report. If we can show that particularly egregious edits like BLP vios are high proportions, then I think it strengthens the case.

I'm sure there are more nuanced ways to refine this data, and the worst thing we could do is build a case based on unreliable or fundamentally flawed data, but I think this gives a good starting point to proceed. Best, Darren-M talk 12:16, 16 January 2021 (UTC)

December 2020 had at least 3510 reverted edits. Data for that month will be uploaded soon, and I updated the graphs. Let me know if anyone has other calculations they want made. Enterprisey (talk!) 04:03, 24 January 2021 (UTC)

Enterprisey, just a question - would you happen to know what proportion of the users were IP addresses, or does the data only include accounts? Pahunkat (talk) 10:06, 26 January 2021 (UTC)

Across all cases, 2011 IPs, 1467 accounts. For just ones ending in a block, 1710 IPs, 1224 accounts. Enterprisey (talk!) 10:18, 26 January 2021 (UTC)

As a result of this finding, I've changed "IP addresses" to "non-autoconfirmed editors" in the proposal, because otherwise the role wouldn't be able to deal with that 40% of the problem. Enterprisey (talk!) 09:47, 28 January 2021 (UTC)

Data up at https://tools-static.wmflabs.org/apersonbot/aiv-analysis-december-2020.v1.json. Format is posted at https://git.sr.ht/~enterprisey/aiv-analysis-jan-2021/tree/master/item/case_format.txt. Enterprisey (talk!) 10:19, 26 January 2021 (UTC)

Update: hit a bug with the January run, restarting; eta 8 to 11 hours. That'll probably come in after I go to bed, so I might start adding January in about 22 hours (23:00 Monday UTC). Enterprisey (talk!) 00:34, 1 February 2021 (UTC)

I think there's a similar role on fawiki

After reading this, it seems similar to a current, working role on fawiki known as an "eliminator" (I first became aware of this through User talk:Pahunkat/Archive 1#Greetings from fawiki!). See here for details. I can get a rough machine translation if needed, the finished proposal will likely have less powers than this role. Pahunkat (talk) 15:52, 25 January 2021 (UTC)

@Pahunkat: Many projects have advanced groups with extra rights, here are the included permissions for fawiki eliminators for example:

fawiki eliminator permissions

Auto-review on rollback (autoreviewrestore) Block other users from editing (block) Change protection levels and edit cascade-protected pages (protect) Delete and undelete specific revisions of pages (deleterevision) Delete pages (delete) Edit restricted pages (extendedconfirmed) Enable two-factor authentication (oathauth-enable) Have one's own edits automatically marked as "checked" (autoreview) Have one's own edits automatically marked as patrolled (autopatrol) Mark others' edits as patrolled (patrol) Mark revisions as being "checked" (review) Mark revisions as being "quality" (validate) Merge the history of pages (mergehistory) Move category pages (move-categorypages) Not create redirects from source pages when moving pages (suppressredirect) Overwrite existing files (reupload) Overwrite existing files uploaded by oneself (reupload-own) Quickly rollback the edits of the last user who edited a particular page (rollback) Upload files (upload) View abuse filters (abusefilter-view) View deleted history entries, without their associated text (deletedhistory) View deleted text and changes between deleted revisions (deletedtext) View detailed abuse log entries (abusefilter-log-detail) View the abuse log (abusefilter-log)

— xaosflux ^Talk 16:04, 25 January 2021 (UTC)

Block other users from editing (block) / Change protection levels and edit cascade-protected pages (protect) /Delete and undelete specific revisions of pages (deleterevision) / Delete pages (delete)

That seems much (too much?) closer to admin than what is proposed here... The point of this, if I read it correctly, is, as implied, as a first response to prevent vandalism by IPs while admins are too busy, not a wholesale mini-admin. 107.190.33.254 (talk) 16:27, 25 January 2021 (UTC)

Very interesting. Just curious, what are the social restrictions on eliminators at fawiki? I’m presuming they can’t use those tools to their full technical extent (otherwise what’s the point of having eliminators vs full admins)?

@107.190: As it relates to this role, you’re right, although long term I guess the purpose is whatever the encyclopaedia needs and consensus will allow. If I were supreme dictator of Wikipedia I’d let it block non-autoconfirmed and IPs and protect pages for such too, ie a full package of tools for anti-vandalism editors to do what they do, and that’d take the load off other admins to do other things. But alas that would probably fail to gain consensus. Though, it is worth noting that some of page mover’s current rights did fail to gain consensus in the original RfC then gained consensus later. ProcrastinatingReader (talk) 16:38, 25 January 2021 (UTC)

Defo too much rights for this proposal. I think it's because fawiki has less contributors then enwiki, but I could be wrong. This shows that proposals like this can work, however, and we might be able to copy other stuff (not just the rights) from this. Pahunkat (talk) 17:40, 25 January 2021 (UTC)

To be clear, we can make a group that contains any custom group of permissions - it doesn't have to copy one from another project identically. — xaosflux ^Talk 17:47, 25 January 2021 (UTC)

Yep, I realize that. I was posting this here in the event that some parts of this may be useful. Pahunkat (talk) 18:26, 25 January 2021 (UTC)

Other objections

I've previously said it might be nice to get a list of the strongest or most frequent expected objections, and deal with them somehow; either by amending the proposal or by having a couple of sentences responding to each in the proposal. I'll list some here. Please feel free to think of more.

• If it turns out that almost all of the slow response time (and extra edits) come from certain times of the day when fewer admins are around, we should just recruit more admins from those times instead of going through with this proposal.
• This role may become excessively visible in the community, or among recent-changes patrollers:
  • It might turn into a de facto prerequisite for RfA.
  • The role might become excessively valued (and thus drive people to quit if they can't get it).
  • The role might contribute to the MMORPG-ification of Wikipedia.
• Blocking someone who shouldn't be blocked is really, really bad, and we shouldn't increase the risk of that.
• (Probably not strong or frequent, just one I thought of.) The proposal is for an hour-long block while you wait for an admin. However, the admin has no way of knowing whether a further block is needed, so the presence of a one-hour block just adds uncertainty (relative to the status quo, where vandalism-only editors obviously get blocked). Admins wouldn't want to make pointless blocks.

A few counter-arguments to the above, and to other arguments (see also #Reading material):

• Judgement. Some admin tasks require very good judgment and can still be difficult to do well, like closing discussions or blocking established users. This role still requires good judgment, but is very easy to do well once you have that judgment (i.e. it is very easy to determine if an editor is clearly engaging in high-speed vandalism). That's the difference, and thus why some people may be qualified for this role but not for adminship.
• Work. This would not create more work for admins; they would already have had to block these editors anyway.
• Blocking people who shouldn't be. Potential solution: more technical restrictions (requiring every edit to have been reverted, for instance).

Enterprisey (talk!) 05:39, 27 January 2021 (UTC)

"requiring every edit to have been reverted, for instance" This might be a bit too restrictive, and some edits which get reverted sometimes do not get the tag if the revert is partial or if there have been intervening edits require manual fixing. This can also be prolematic if, say, its a dynamic IP which has been assigned to other editors in the past (ex Special:Contributions/73.235.91.43), although that might be fixed by a time limit on the check, or if it is a shared IP and multiple edits by multiple persons (not all of whom are reverted vandalism - allegedly probably a fringe case, but just noting). Also, in some cases, when an editor is clearly only vandalising and at a rapid rate (supposedly one of the things this is supposed to help against), it would be more efficient to first block them (as a preventive measure against further vandalism - i.e. WP:BLOCK "Blocks are used to prevent damage or disruption to Wikipedia" [emphasis mine]) and then revert the reminder of their edits. I understand we want this to have as clear as possible restrictions and guidelines to alleviate any concerns about potential misuse or errors, but we must be pragmatic about it: it still needs to be an effective tool - especially if we want to be able to judge its effectiveness on concrete data RandomCanadian (talk / contribs) 21:43, 27 January 2021 (UTC)

I think any further restrictions along these lines are unlikely to draw more supports, personally, but could make the tool less attractive to apply for, or less useful to actually use, which will make it inadequate at addressing the problems. You can’t really legislate to make up for a lack of trust, and these suggestions only really work if you don’t trust the user of the tool. In such a case, they shouldn’t have access to the tool in the first place. Plus, they could just use the revert all tool before blocking, so bypassing it would be trivial. ProcrastinatingReader (talk) 22:35, 27 January 2021 (UTC)

The main, repeated objections I gathered were that it makes RfA harder and that editors who don't possess the right judgement will end up with the right. I don't think further technical restrictions fix either. As for RfA, that's not my area of expertise. I don't think it would make the biggest difference, but even if it does with ~10-20 successful admins per year, it's probably a sailed ship. On judgement, a good granting process would account for it, but I don't think the current granting process is weak, and even if it is I don't know how to tighten it further without making it basically RfA-lite. If the role is too restricted it becomes redundant.

I think one of the biggest barriers to preventing abuse is careful selection of editors, and the fact that blocks are reported to a separate section at AIV for an actual admin to tick off before they disappear. It then becomes very difficult to abuse this tool and fly under the radar if one does. Even admins aren't subject to that kind of scrutiny - having their actions reported to a centralised venue for a "peer review" / someone else ticking it off. Possibly this should be relaxed such that blocks disappear off the recent list after 72 hours or so. ProcrastinatingReader (talk) 13:33, 28 January 2021 (UTC)

There were talks earlier about similar rights to what is proposed on other wikis. Should we make mention of these and try to take a look if there's any indication those are misused or anything else which will surely be a frequent point of opposition against this (or on the contrary, how successful they are)? RandomCanadian (talk / contribs) 23:28, 28 January 2021 (UTC)

Unlikely it will help in my view. The proposal is already very lengthy. Attention span is also a factor to keep in mind. Some mentioned above the concept of metawiki limited admin above and it was thought that wouldn’t fly here. It’s dubious whether the community will consider what other projects do and use that as evidence, especially since a good portion of the community thinks other language projects have undeveloped policies, sourcing standards, etc. ProcrastinatingReader (talk) 23:33, 28 January 2021 (UTC)

In which case the question is "what remains outstanding"? Otherwise we can wait some more time in case there we want to let some more users give their opinion, i.e. quoting from above "Enterprisey suggested surveying some normal content creators / the average editor, non-admins". Of course, you are the one behind this so when you think the time is right you're free to get this live. I note that 5 kb, while longer than typical RfC questions, isn't particularly long to read through. RandomCanadian (talk / contribs) 01:31, 29 January 2021 (UTC)

For my part I'd like to see the Nov data for User:Enterprisey/AIV analysis, scatter graph updated, and one or two graphs embedded into the main proposal. For those who haven't already made up their mind, maybe the data in a good visual form right in their face will help. More creative graphing and interpretations of the raw data could be interesting, but that's not my area of expertise, so unless someone who is good at that wants to take a look at Enterprisey's raw data (or if someone happens to know who to ask)...

I'm waiting on one more person's thoughts but otherwise I think it's mostly good to go live, possibly this weekend. I'm not sure it can be much better, other than Enterprisey's idea of addressing predictable opposes in the proposal, perhaps within a sub-section under discussion (which may be helpful, and I've added my own thoughts in my previous message, particularly re RfA statistics etc which may be worth mentioning that it's a sailed ship). However, drafting successful proposals is not my area of expertise. Those who I consulted who do have a good track record of pushing through tough proposals, well, I incorporated as much of their thoughts as I could parse, but there's some skepticism on the outcome (which can only really be tested by putting it live, I guess). @Guy Macon: thoughts? ProcrastinatingReader (talk) 01:59, 29 January 2021 (UTC)

Further objections

I spoke with some smart people. They had a few concerns:

1. the actually harmful editors get instantly blocked at any time of day, making AIV response time a red herring (that is, for example, first demonstrate that "bad" accounts are getting removed as stale instead of blocked)
2. if someone couldn't pass RfA, we wouldn't want them doing this
3. unbundling makes RfA harder
4. we over-block at AIV already
5. if we're doing this, it should be protection, not blocking
6. removing this permission from someone will be massively painful (ask any PERM admin)
7. a trial means nothing because the bad blocks will only start after 6-12 months (aka: our existing auditing capabilities are a bad match for this tool / IPs won't complain at AN)

And, as a general note, that if the need for this is demonstrated well enough (meaning that it isn't now), people will overlook minor objections. I think these are a reasonable preview of the Oppose section, and that we absolutely must address these (at least the first) if this is to have a chance. Enterprisey (talk!) 03:11, 1 February 2021 (UTC)

Another one I just thought of: just as there's no guarantee an admin will be around, there's no guarantee a responder will be around either. Enterprisey (talk!) 09:19, 1 February 2021 (UTC)

Agree with 5 (with blocking, playing whack-a-mole with IP hoppers is not any different for admins than users who would get this right - maybe users would be faster to respond, but then you'd still have the next mole to deal with...). I'd like more proof of 4. 6 and 7 seem like conjecture? RandomCanadian (talk / contribs) 16:30, 1 February 2021 (UTC)

I disagree with most as I say on IRC:

For example, imo #3 is moot given only 10-20 RfAs pass annually, unless someone has a passable RfA reform in their pocket. For #2 I suspect the people would/should pass RfA if they actually ran. #5 is a violation of the protection policy; we don’t semi protect 1 or 10 pages because *one editor* is vandalising them, hence stopping everyone from editing them. #7 and #4 I don’t believe in because blocks are still reported to AIV in some feed for admin review. Such blocks are under even more scrutiny than admin blocks, which aren't peer reviewed.

I agree with just as there's no guarantee an admin will be around, there's no guarantee a responder will be around either. -- there's the argument that all responders could be admins (which includes blocking). The crux of the argument is whether they'd pass RfA, really. I don’t doubt these opposes will come up. I just think they’re already addressed and I’m not sure they can be addressed further, but I’m open to ideas. Since an RfC will take up a bunch of community time, if we think these arguments won't sway people then it's perhaps not worth going ahead with this, as it would just be a dead-on-arrival time sink. ProcrastinatingReader (talk) 19:39, 2 February 2021 (UTC)

@Enterprisey: what do we want to do here? If the cost of satisfying some is to completely gut this proposal, then it's failed even if it passes since it won't actually reduce the problems and thus fail the trial. If you have answers to any of those concerns I'm happy to hear but imo they're already addressed or are too speculative. If we have nothing further I think we gotta decide to either add the Jan data and proceed with an RfC, or call off the proposal if we think it's DOA. ProcrastinatingReader (talk) 03:46, 11 February 2021 (UTC)

ProcrastinatingReader, I would certainly like to see this proceed to a vote, although I've been a bit busy with other things lately. I agree we don't have much we can do to address these. However, I think we can still budge the needle a bit...

• For objection #1, I would like to go through the worst cases (by revert number and/or delayed resolution) and categorize a few (all?) by whether they were actually "bad", to try to refute the statement "the actually 'bad' stuff gets dealt with quickly". Strong enough evidence here would be pretty darn effective, I think.
• For #2, (this is not a change to make, but a counterargument) persuading people to run is pretty tough these days (example).
• For #5... I dunno? 15-minute protection? Having responded to cases where an article got linked from a high-traffic source (really the only case in which this role would be using protection), 15 minutes is all we need for an admin to come by, honestly.
• For #6, what do you/everyone think about requiring that this only ever be temp-granted for 6/12 months (restriction could be lifted later by RfC if we think that's a good idea)?

And for the general objection of "duplicate admin work", I would potentially support a sentence specifying that admins should respond to these cases with a strong bias towards taking further admin action, although that's a bit heavy on the micromanagement on second thought. Another idea I had was to use an even-shorter block time, like 30 or 45 minutes, to encourage admins to respond; that's around the median response time, anyway. (Assuming high-quality reports get responded to quickly, which we'll confirm after I've done the above data analysis.) A 30-minute block won't tempt the responding admin to think it'll probably be fine without further action. It also reduces the fallout for a bad block. Enterprisey (talk!) 09:54, 11 February 2021 (UTC)

Bullet #1 seems okay. #2 yes, and also anti-vandalism alone isn’t sufficient to pass RfA these days anyway I think, if you believe conventional wisdom, and hasn’t been for years. For #3, protection policy violation and still means protecting many pages. Bullet #4 doesn’t work I think. For one, even this mini process isn’t great. 48 hours of heightened scrutiny where personal attacks are permissible? Meh. Doing this every 6 months or year doesn’t make sense. Plus they’d have to ask someone to renominate, which is awkward. If automatic, That’s like steward confirmations, which is too much for a one hour block tool. Admins don’t even go through reconfirmations, and any single admin can already explicitly revoke the perm. Shorter block time won’t change anything - I don’t think it’s 1 hour that concerns people, and with 30 minutes people rightly think “what’s the point”? If gutting this tool so much is the only thing that makes it pass, it’s better to consider it a failed proposal. ProcrastinatingReader (talk) 22:16, 11 February 2021 (UTC)

Something is better than nothing. I think both 15 minutes of protection (I checked SEMI and I think it falls within policy) and 30/45-minute block durations is an improvement to the proposal; as the graphs show, the median response time is pretty fast. Temp grants can be debated at the post-trial RfC, since it's a moot point until then. Enterprisey (talk!) 23:55, 11 February 2021 (UTC)

• Some of these objections were mine, I think #2 was, so I’ll rephrase it in a slightly less diplomatic way than Enterprisey phrase it: anyone wanting this permission but not wanting to go through the scrutiny of RfA would be proof to me that the individual was unsuitable for the position. Blocks, especially of the unknown users who get reported to AIV have the ability to scare off good editors from the project. Unbundled rights are effectively unaccountable to anyone (see the point about how it’s next to impossible to remove one), and the type of editor who could pass a nominating process for this would never have it removed. The willingness to go through RfA shows a willingness to open oneself up to scrutiny, which is really hard, as feedback sucks. If someone wants to be able to block people without opening themselves up to the level of community feedback that comes with RfA or the ability to have your actions reviewed at AN in the drop of a pin, I don’t trust them with the ability to block. TonyBallioni (talk) 00:20, 12 February 2021 (UTC)

  @TonyBallioni: I guess personally I think RfA, as with any permissions process, is merely a means to an end. And likely not the most perfect process of achieving the goal of granting permissions to take protective actions whilst filtering out those incompetent to do that using hard tools like the block button. I guess the same logic (re scrutiny and community feedback) could be applied to various unbundled tools. I guess that point is an ideological opposition, which is valid of course, and so there's nothing this proposal could do to overcome it. I think people with this role are still subject to review of actions at AN, same as how template editors and edit filter managers can be dragged to AN/ANI. I am curious about Unbundled rights are effectively unaccountable to anyone (see the point about how it’s next to impossible to remove one), and the type of editor who could pass a nominating process for this would never have it removed. though -- is there a reason you think the Any administrator who suspects the tool has been misused may unilaterally revoke it immediately and notify the administrators' noticeboard of the issue. clause in the "Revocation" section won't work? ProcrastinatingReader (talk) 16:09, 12 February 2021 (UTC)

• Also, another one: "you can just ping an admin on IRC or whatever". Might be worth having a trial for an IRC channel just for this purpose - "hey admins, please block/protect here" - if it works, we can pack this up, and if it fails, that's more data for us. Enterprisey (talk!) 03:32, 12 February 2021 (UTC)

AIV accuracy requirement

Might be useful to require something like 99% of your AIV reports to have been blocked over the past six months (minimum 10 reports). Enterprisey (talk!) 05:40, 27 January 2021 (UTC)

To effectively determine "99%" you'd need more than 10 reports (as 10/10 is 100%, but 9/10 is 90%). Support the general idea that a track record of effective vandalism reporting is a must (as already present in the proposal), but don't know how much we can quantify if using hard numbers. Don't think (from the "ultimately this will get !voted on" point) that including this would have a measurable impact - there's already the requirement that multiple admins approve any nomination... Remember also, no matter the specifics, that Wikipedia isn't exactly a bureaucracy and that people will still vote on this as a matter of a broader principle (should "admin" tools be available to some non-admin users?) - hopefully the proposal is sensible enough that it could be accepted, but adding extra technicalities in the hope that will change anyone's mind is likely to be just a waste of our time: after all, even adminship isn't granted based on some numeric criteria (the personal, non-consensus criteria of some editors who go to great lengths to set them out on their user subpages aside), other than the outcome of the RfA. RandomCanadian (talk / contribs) 01:01, 28 January 2021 (UTC)

I agree with all of that, and I certainly see that this shouldn't be a hard requirement. I just want to make it easier for people to check for themselves whether they'd qualify. I agree in particular that "know what you're doing" is perfectly fine for us to use as a guideline, but I don't think it's easy for the average recent-changes patroller to evaluate that. (Maybe I underestimate them.) On the other hand, since you already need to ask someone else to nominate you, the problem is mostly solved, and we'd only need to consider something like this if people report that they're getting spammed. On the other other hand, just "any other editor in good standing" isn't 100% guaranteed to give good advice. I dunno... Enterprisey (talk!) 02:36, 28 January 2021 (UTC)

My 2c:

• I don't think a stricter criteria is likely to work (for example, 90/100 blocked, but 10 not declined but rather removed as stale, would technically fail "99% AIV reports blocked").
• Agree with you that the nomination mostly fixes the problem. If it turns out non-admins are nominating people who don't qualify the nominating criteria could be made more strict to admin nominations only
• Trial amendments can be made per Wikipedia:Requests_for_comment/Responder_role#Trial: To ensure smooth operation, during the trial admins may make changes to tighten, but not loosen, how this role is used or granted. If there turns out to be a problem with nominations during trial, it could be tweaked. I don't think it's a good idea to preempt too much and make the right too restricted to be useful. If the current proposal cannot pass, I don't think any proposal can. ProcrastinatingReader (talk) 13:40, 28 January 2021 (UTC)

Extension to non-autoconfirmed

I'm not sure extending from IPs only to non-autoconfirmed is a good idea. I mean, I agree long term that's where the tools should be, but I do think it may meaningfully change this proposal and its acceptability. If we can push the minimal IP version through, I think that's a better thing to aim for, then look for after the trial period to extend it to non-AC accounts. It's better to get something through, which can deal with a good % of issues, than nothing. And I think people have a little more coldness towards IPs than they do accounts. ProcrastinatingReader (talk) 13:15, 29 January 2021 (UTC)

I agree. Besides, I wouldn't be surprised if the number of vandalism-only accounts I end up reporting are at a 1:10 or 1:20 ratio compared to the IPs I've reported to AIV. Perryprog (talk) 20:44, 29 January 2021 (UTC)

Confirmation bias? Anyway, both IPs and non-ACs are frequent sources of vandalism: dated numbers from WP:IPDIS suggest the ratio is closer to 1:4 or 1:5 (although this is a number for all registered "users": taking into account bots and all AC accounts, the numbers between IPs and non-ACs are probably closer than what we think). In any case, both kinds regularly get blocked at AIV. Some non-ACs (caught one yesterday) are also obvious LTAs so they'd be subject to WP:RBI, though I don't know if that is within the scope of this proposal. RandomCanadian (talk / contribs) 22:56, 29 January 2021 (UTC)

For Nov/Dec 2020, there were 671 blocked IPs with 2+ reverted edits and 367 blocked accounts with 2+ reverted edits; for 1+ reverted edits, there are 1247 IPs and 641 accounts. So it's about a third. If we think adding accounts would diminish support, then absolutely get rid of it; I'm not sure either way on that point, though. Enterprisey (talk!) 00:20, 30 January 2021 (UTC)

I think limiting the scope to IPs won't hurt, and broadening it to non-AC accounts wouldn't help, but could hurt. In other words, I think it'd better to start with a smaller scope and widen if necessary than to do the opposite. Perryprog (talk) 00:41, 30 January 2021 (UTC)

Works for me. Enterprisey (talk!) 02:06, 30 January 2021 (UTC)

In that case, even if its not ideal, nihil obstat from me too. RandomCanadian (talk / contribs) 02:50, 30 January 2021 (UTC)

Evidently it is confirmation bias, although it doesn't help that I've been doing less RCP so most of my recent AIV reports are the result of watching out for this user's activity... Perryprog (talk) 00:41, 30 January 2021 (UTC)

ProcrastinatingReader, well, new accounts could also be blocked for having an inappropriate username, in which case it makes sense to block non-autoconfirmed accounts. Steve M (talk) 01:18, 6 February 2021 (UTC)

Example examples

(Side note: I only realized after I wrote this that the block length for the role was reduced to one hour—which I think makes sense considering the purpose is ultimately to wait for an AIV to go through—so the example I provide here isn't quite as good as I wanted it to be.)

I'm wondering if it would be helpful to have a couple of historic examples of places where it would or would not be acceptable circumstances to block IPs in, along with a rationale on why it would or would not be an in-scope use of the role.

As an example example (and partly a question of whether this should be considered an acceptable use-case for the role), I'll use the cancelled platforms LTA. For a bit of background, they are Ireland (typically Dublin) Vodafone IPs that typically add categories like cancelled Xbox games and the like to articles on often kids-targeted video games. They are always blatantly obvious, fairly prolific, and pop up every few days on a different IP. The key bits are:

• The IPs have always needed to be blocked in order to prevent further disruption.
• Their edits are not typically rapid—maybe around five in an hour.
• Their edits are more "disruptive" than "vandalism".
• Typically a short block—around 24 hours—is all that's needed, as they typically only edit in short sessions.
• Speaking from personal experience, I've never had an AIV report for them wait long enough that they ended up causing that much more disruption.

So: while I'm unsure if this is something that should be considered in-scope for this role (I'm personally leaning towards no), but either way I think this is a good example borderline case that could set more definitively what's an acceptable use for the role. Perryprog (talk) 02:46, 31 January 2021 (UTC)

I’d rather leave these variables for the trial, to be honest, rather than excessive proposal legislation. If something doesn’t make the proposal more acceptable, I don’t think it’s worth adding. This particular situation came up in the first section on the talk. Generally, I think this proposal is starting to get too complex, which is why I want it to go live ASAP (as soon as the January data is collected by enterprisey). ProcrastinatingReader (talk) 02:55, 31 January 2021 (UTC)

Sounds good to me :). Perryprog (talk) 02:56, 31 January 2021 (UTC)

Looking at the stats, surprised that there are fewer reports during what I assume would be the vandalism peak starting in the evening (and that the reports apparently take so much to get acted upon) on the North-American east coast (Eastern time) (the EnterpriseyBot index is nearly always at very high during that period), around 0000-0400Z... Are you sure there isn't some time zone error in the data? RandomCanadian (talk / contribs) 04:35, 31 January 2021 (UTC)

I suppose it looks suspicious, but I did a few spot checks and it all looks okay, at least the data - you can open one of the JSON files, pick an aiv_removal_revid, and check that the timestamps match the ones in the file. The analysis Python scripts are all available at https://git.sr.ht/~enterprisey/aiv-analysis-jan-2021/tree/master/item/analyze. I reran one of the graphs while specifying the UTC timezone and the graph looked the same. Enterprisey (talk!) 04:50, 31 January 2021 (UTC)

That means that the bot might not be measuring the right thing: reverts per minute might be an ineffective measure for many reasons. This could warrant further investigation, but not here. RandomCanadian (talk / contribs) 05:04, 31 January 2021 (UTC)

Oh yeah, to further the tangent (sorry), substantive accuracy concerns were raised at the BRFA for that. Ideally we'd go off the Huggle or ClueBot scores, but I haven't gotten around to doing that. Enterprisey (talk!) 05:58, 31 January 2021 (UTC)

My thoughts on this permission (please respond what you think)

• It has good potential, especially for users that revert vandalism regularly and want to become an admin. If someone is uses this right properly for a long time, that should be a huge plus on any RFA they make
• It should he a highly sensitive right - on par with template editor, but for reverting vandalism instead of editing templates.

Steve M (talk) 01:41, 6 February 2021 (UTC)

Ok, a few days of further consideration, and well I must agree that this tool would indeed be very useful. If we frame it more in the direction proposed by Steve M that might make it more palatable to some of the opposers, but then the group of users will be restricted. But then again, even a few more users that can deal with vandalism would surely not be unproductive. RandomCanadian (talk / contribs) 21:43, 10 February 2021 (UTC)

RandomCanadian, yes. However, you should be allowed to nominate yourself like a real RFA, as otherwise there will be incentives for gaming by asking other editors, making sock puppets, or emailing them. Steve M (talk) 21:46, 10 February 2021 (UTC)

Remember that the initial proposal is for a trial of this for a few months. If the trial is successful, I'd see no objection to that, and possibly further anti-vandal tools such as semi-protection and the like. RandomCanadian (talk / contribs) 21:47, 10 February 2021 (UTC)

Yeah, I think disallowing self-nomination—at least during the trial period—might not be a bad idea to "quality control" things a little bit. I don't have a preference either way, though. Perryprog (talk) 21:58, 10 February 2021 (UTC)

Perryprog, yes, but there will be a lot of gaming. Gaming is more dangerous than inexperienced users, as gaming can get the title, while nominations by inexperienced users can be closed. I think the best idea is to make it so that you have to be extended confirmed to request? I think that is the best solution. Steve M (talk) 22:02, 10 February 2021 (UTC)

Steve M, that's a good point—I think that's a fair enough reason to allow self-nominations, then. There's already a 1,000 edit and 1 year tenure requirement, so EC might be a bit redundant with that. Perryprog (talk) 22:04, 10 February 2021 (UTC)

Well, I mean, even RfA and some other advanced permissions don't technically have an EC requirement, though as a matter of fact I don't think you can show that you have the experience for these without at least EC, and then some... RandomCanadian (talk / contribs) 22:06, 10 February 2021 (UTC)

Perryprog, this should also apply for username hard blocks, as a username saying "Wikipedia is stupid" doesn't need much debate to block. Steve M (talk) 22:26, 10 February 2021 (UTC)

Steve M, I'm not sure I know what you mean; currently the role is for IPs only, not accounts. Perryprog (talk) 22:39, 10 February 2021 (UTC)

Perryprog, nevermind, then. I was just wondering if this can go to non-autoconfirmed users, as almost all vandalism-only accounts are not autoconfirmed. Steve M (talk) 22:40, 10 February 2021 (UTC)

I don't think socking to nominate is a likely issue. If it happens, nominations can be limited to ECP or admin during the trial. A sock nom is unlikely to succeed anyway, so one would be shooting themselves in the foot. Not really comparable to RfA imo; the rough bars there are set with long precedent, and most self noms fail anyway. No bars here, and it's ideal that people with no chance don't self-nom and go through a discouraging process. ProcrastinatingReader (talk) 03:40, 11 February 2021 (UTC)

The proposal as it stands is "IPs only", might eventually be expended to non-AC users too, and potentially semi-protection, but we need to start somewhere to see if its effective. RandomCanadian (talk / contribs) 23:10, 10 February 2021 (UTC)

My thoughts on this proposal

I am a regular RCP patroller, but I do not think that giving non-admins the block button is a good idea. When patrolling, I regularly see some of our most experienced anti-vandals erroneously hitting the rollback button on good-faith (but unhelpful) edits and making AIV reports far too early. Furthermore, I am seeing administrators (I don't want to say who) block IP addresses over one minor act of vandalism. I feel that this is going to get out of hand. If this proposal does pass, we may need stricter requirements. Maybe we could also require someone to have both pending changes and rollback permissions to be eligible for this proposed right? Scorpions13256 (talk) 05:51, 11 February 2021 (UTC)

I would like to add to this. I feel admins should only use the block button. I have seen quite a few reports at the AIV for users/IPs whose edits are not completely vandalism or obvious spam, but have been reported as such. Which is why this permission could get misused by someone who doesn't have a clear understanding of what constitutes as vandalism, and treats unhelpful edits as such. Ashleyyoursmile! 06:45, 11 February 2021 (UTC)

Thank you both for taking a look at this. You raised great points. There are indeed a lot of premature or mistaken reports. On the other hand, while I was collecting data, I collected some statistics on individual editors, specifically on what percent of reports by a given editor resulted in a block. I found more than 10 editors with 100% records and many editors with >99% or >95% records, several with a few hundred reports (during just the three months I checked). So I don't think we'll have a problem finding people who won't make mistakes, since judging if someone's performing high-speed blatant vandalism is much easier than judging if a single edit is vandalism. I also think people reviewing candidates for this will be careful (at least initially, I guess...).

The problem of overblocking by administrators is also serious, and this proposal does have a big risk of making that worse. However, editors who would've gotten blocked using this role would hopefully have been reported to AIV anyway. I don't think solving that problem is related to this RfC. I even think whether this role will work is independent of whether overblocking is a problem.

Off-topic: if you have specific examples of overblocking in mind, you could message me on my talk page or via email, or maybe an arbitrator if it's really bad; I could certainly think of some examples myself (that's not good). Some IPs that get blocked after one edit are part of a larger "attack" or recognizable as LTAs; I blocked several myself due to this recently. Enterprisey (talk!) 10:14, 11 February 2021 (UTC)

(forgot to ping Scorpions13256 and Ashleyyoursmile. I'm also a little curious where you learned about this proposal from; I wonder who's linked to it recently. Enterprisey (talk!) 10:15, 11 February 2021 (UTC))

Hello Enterprisey, thank you for your response. About the proposal, Pahunkat suggested to me to take a look at it. Ashleyyoursmile! 10:21, 11 February 2021 (UTC)

I saw it on CLCStudent's talk page. Scorpions13256 (talk) 11:26, 11 February 2021 (UTC)

Scorpions13256, yes. THat's why I suggested it be a template-editor level right. Steve M (talk) 14:39, 11 February 2021 (UTC)

Pending changes and rollback are shall-grant permissions. They're given out to anything with a potential heartbeat and some semblance of knowing what vandalism is. This right is, of course, on a different level and someone who cannot even get rollback wouldn't get this. They just wouldn't get past the existing granting process (consensus support from admins). Stating it as a requirement specifically actually makes the requirements seem lower, since it implies this right is near rollback level, or that rollbacker is on the step of progression to this right. This right is around TE-level, which should show in the requirements (which were based from the TPE ones). ProcrastinatingReader (talk) 14:45, 11 February 2021 (UTC)

Huh

• I had an idea like this at one point, except is was for protection: Wikipedia:Village pump (proposals)/Archive 152#User-right that allows non-admins to Semi-protect pages. Although honestly, this makes more sense than what I proposed. Moneytrees🏝️^{Talk/CCI help} 00:14, 12 February 2021 (UTC)
  • Interesting! Aspects of this certainly have similarities with your and NeilN’s proposals. ProcrastinatingReader (talk) 01:42, 12 February 2021 (UTC)
    • I mean, the best option would be both in combination, but blocking is usually effective except when the page is the target of LTA or "some random internet meme" type vandalism. That, and blocking also works for vandals which get stopped by the edit filter, ex. [4] RandomCanadian (talk / contribs) 04:42, 21 February 2021 (UTC)

  I do like the idea of allowing non-admins to temporarily semi, the issue was that for this rapid-fire vandalism, they'd just move on —valereee (talk) 21:14, 21 February 2021 (UTC)

Comments by JavaHurricane

In its current state, I find this proposal to have several flaws:

1. Just allowing to block IPs is a bad idea: when there's a big backlog and no admin around, VOAs are also just as problematic.
2. 1 hour is too little: I suggest 12 hours as a better idea, taking into account VOAs. 1 hour may not be enough in case vandals pop up at an odd time.
3. Blocking accounts for blatant NOTHERE, NONAZIS, spamming, LTA socking, and spambots, etc. should be an option. Less clear-cut cases should be deferred to AN/I.
4. "Users with this role may not re-block the same IP address in any 7 day period." I don't understand why, so I'd appreciate if someone could help me here.
5. Why require two sysops' support? Are sysops some "special" Wikipedians that their opinion is more important, or otherwise more informed, their normal Wikipedians?
6. We still do allow self-noms at RfA (though I've not seen any pass lately for that cause) so why are self-noms not allowed?
7. Overall, "responder" is still a very weak role. If it is to be implemented, there should also be an ability to enable PCR or semiprotection (for a short term, say 12-24 hours at most) in case of an RfPP backlog. There could also be an argument to add the limited ability to delete pages in clear-cut cases, and use Special:Undelete to, say, see if G4 is needed. (I wouldn't particularly support the delete/undelete ability though.)

Overall, I think that the responder role is not a very good idea: the block button is a very dangerous tool and ideally remain a part of the sysop toolkit only. The root of the problem, in my opinion, lies in the lack of admins from Asian timezones who are interested in RfPP, AIV, UAA, etc., and the main issue here is the toxicity of RfA. A better way to deal with these backlogs is to get new admins from these timezones, and the correct path, in my opinion, is in RfA reform, not in unbundling the dangerous block button. Blocking requires utmost discretion, and the only way to give out the ability to block should be RfA (IMO), and personally I feel that the amount of vetting required for granting this right is too little. JavaHurricane 05:34, 11 March 2021 (UTC)

@JavaHurricane: Thanks for your comments! 1-2-3 agree; I assume someone who would get this would be trusted and experienced enough to know what it's all about. 4. if the same IP needs reblocking within a short period then it probably needs a longer block thus actual admin attention (as the proposal is worded) 5: in theory yes it's not big deal; in practice given the laundry list requirements of some editors it is a big deal [whether that is right or not is another issue]. 7. Too little and it's ineffective; too much and we'll have people complaining this is a "mini-admin" role and that those interested should just run at RfA instead (nevermind that anti-vandalism isn't enough as a sole reason to pass RfA) RandomCanadian (talk / contribs) 05:47, 11 March 2021 (UTC)

Point 7 is precisely the reason why I think the way ahead is making RfA better and getting new sysops from Asia and Africa than creating a responder role. If we can trust someone with the block button, we should also be able to trust them with the protection and deletion buttons. JavaHurricane 01:48, 12 March 2021 (UTC)

@JavaHurricane: Point 7 is true, but it's been 20 years of this site. Countless people presumably have tried that and failed, which (to me) indicates that it just isn't possible under present circumstances. ProcrastinatingReader (talk) 21:47, 17 April 2021 (UTC)

Regarding points raised by JavaHurricane, for me point 6 kills the entire proposal. I cannot support a proposal where self-noms are not allowed. We need to move this process as far away from an RfA-type format, and it should not be anything even close to a popularity contest. Any experienced editor must be allowed to nominate themselves and be judged on their record and experience. No cliquishness, please, this is not high school. Nsk92 (talk) 20:50, 17 April 2021 (UTC)

@Nsk92: The aim was to create a minimally viable proposal that could pass. I'm no big fan of seeing admins as a 'special' type of editor, but it's a fact that many editors do see them that way. Also narrowing the contribution pool might've help reduce the whole "bring up random diffs" unpleasantness. Ideally some of the requirements would be loosened after the 3 month trial, in the confirmation RfC.

The idea behind nom requirement was two-fold: a) to stop inexperienced editors trying and failing to get the right, which makes it look harder to 'get' than it actually is; b) to help experienced editors gain it. My anecdotal experience asking for rights, and seeing how certain unbundled rights like WP:EFH are requested at EFN, leads me to believe many editors suitable for a right don't ask for it whilst inexperienced ones do (some others agree with the unpleasantness of PERM). I felt a culture where it's clear the onus is on another editor to nominate, and that they can do so freely and it doesn't need to be considered some kind of special 'thing', was more comfortable and would make for more editors with the right. But it does seem others don't see it the same way. ProcrastinatingReader (talk) 21:45, 17 April 2021 (UTC)

I remember from my own requests for some of the more basic tools at PERM that many new editors do seem to make requests which are unlikely to be granted (even when there are unambiguous quantitative requirements which they don't meet). Now of course, depending on how many users we expect to get this role, and how high a level of scrutiny we want to allow blocking obvious vandals and LTAs, a separate process than PERM might be ok. Though the more advanced rights (Template Editor, for ex.) don't seem to have too many requests, given I think that high numerical standards. RandomCanadian (talk / contribs) 22:00, 17 April 2021 (UTC)

Let me put it as politely as I can: I consider the requirement to have a nominator for something as basic as this proposed userright an insult to experienced editors. We don't require nominations for RfA, RfB and Arbcom, and we sure as hell are not going to subject experienced editors to the indignity of such a requirement here. It's absurd. If you want to limit the pool of applicants, raise the minimum edit requirement, if needed dramatically, say to 10K edits. Possibly require an account to be open for at least 2 years with some sort of additional requirements. But get rid of requiring a nominator. Nsk92 (talk) 22:30, 17 April 2021 (UTC)

Some Suggestions

Hello. Overall I think this proposal is really good, and has great potential. I do have a few suggestions/concerns.

1. Change the requirement to 2500 edits, and also needs to have rollback rights to be a responder. Some of the concerns are that this could be abused, and I think making the requirements higher would help that. Noah ^💬 14:40, 30 March 2021 (UTC)

Comments by Nsk92

The idea behind this proposal is highly commendable and the current proposal is a good starting point. However, many of the details are problematic.

1. Get rid of the requirement for a nominator. See my comments in "Comments by JavaHurricane" section above.
2. Get rid of the requirement that the requesting editor "have a track record of expert-level competence in anti-vandalism work." Any sufficiently experienced and trustworthy editor should be able to request and get this userright. Blocking an obvious vandal does not require "expert-level competence". Content-oriented editors should be able to request and get this userright and use on as needed basis. No formal AIV/SPI/LTA edit filter requirements, just require having the rollback for at least 6 months.
3. Raise the "experienced" bar. 1K edits is too low, and 1 year of editing is probably too short. I'd say 5K edits minimum, and 2 years of having an account. A clean block record for a year.
4. Remove the requirement of WP:AN notification when somebody applies. The application process should have no resemblance to RfA. It should just be a standard WP:PERM procedure.
5. I think the two-admin approval requirement is a bit of an overkill, but I can live with it.
6. The one-hour block limit is too short. The goal here is to relieve the work of admins at AIV. One-hour blocks will likely not achieve that goal. Raise the limit to 24 hours at least.
7. I agree that the blocks should be limited to obvious active vandalism only, possibly with addition of gross BLP violations/abuse. Anything else (NOTHERE, NONAZIS, edit warring, incivility, NPA, content disputes, other types of disruptive editing) should not be eligible for such blocks.
8. Perhaps something needs to be discussed about range blocks.
9. I would consider allowing blocks of vandals that have not been reported to AIV. Making a manual AIV report is a time and labor consuming process. In cases of dealing with obvious aggressive vandalism it should not be necessary.

Coming back to point number 2, I think the current proposal makes a mistake by targeting the pool of "professional" vandal fighters. Many of them tend to be less experienced WP editors, with limited knowledge of Wikipedia as a whole. I believe the correct pool to target here is all sufficiently experienced and trustworthy editors. Nsk92 (talk) 23:15, 17 April 2021 (UTC)

No. 3 I'm not sure raising the duration is necessary. Even stuff like template editor only de iure requires 6 months (this is supposed to be at about the same level) - higher edit counts might be more effective (and vandal fighting quickly ups an edit count, so it would be understandable requiring a higher number). 5 - agree. 9. agree, but not for the same reasons - as for AIV reports, that's usually rather quick with tools like WP:RW or WP:TW. RandomCanadian (talk / contribs) 23:23, 17 April 2021 (UTC)

Regarding the duration in number 3, I don't have particularly strong feelings. Raising the age of account requirement is one of the ways to limit the applicant pool and to filter out inexperienced editors, which is a concern here, as I understand. Perhaps 1 years is enough. I'd like to see some minimal number of non-automated edits. Nsk92 (talk) 23:45, 17 April 2021 (UTC)

@Nsk92: Might I ask why you want x number of non-automated of applicants? -- Asartea ^{Talk | Contribs} 07:38, 18 April 2021 (UTC)

I am not sure, but it has to be a meaningful number, at least 500, or maybe 1K. Nsk92 (talk) 10:27, 18 April 2021 (UTC)

Thanks for these comments. The issue is really in how some people see the proposal. There's a group of editors, like yourself, who believe it should be targeted at all sufficiently experienced and trustworthy editors. There's also the group that fundamentally and ideologically believe block should not be unbundled. There are others who see this as a "vandal fighter" group, and others who see it as putting a halt to rapid vandalism giving time for an admin to respond. I feel the current proposal, very roughly, is what is most palatable for the various groups (except strict ideological concerns).

If this proposal ever reached RfC and was approved, I would expect further tweaks in the confirmation RfC after the trial ends, once people realise the wiki isn't going to explode with this role. Further tweaks later also being possible (consensus for most of the individual rights associated with page mover actually failed in the original RfC; they were added later). Overall, I think requirements 2, 4, 5 are necessary for a "minimally viable proposal". Better to have something passed and adjusted after 3 months to loosen the excessive protections, verses mark it all as {{failed}} and {{historical}}, IMO. This same ideology was the reason for #6, but I don't think (given the feedback on this page) anyone has felt that limiting the time period actually makes the proposal more palatable. I feel the nominator requirement hasn't had a great reception overall, and probably agree that can be stripped. ProcrastinatingReader (talk) 23:55, 17 April 2021 (UTC)

To add, I personally agree that I believe the correct pool to target here is all sufficiently experienced and trustworthy editors., and any specific tweaks on making that more clear would be great. Perhaps we can make clear that 'demonstrated need' is not required? Still, many experienced editors don't have experience with WP:NOTVAND, how could we ensure this if they have no track record at AIV? ProcrastinatingReader (talk) 23:58, 17 April 2021 (UTC)

To answer your last question, I think that if the edit count and age of account requirement are set sufficiently high (plus some other formal requirements such as having rollback for a certain amount of time and maybe something else), we would not need to require any formal WP:NOTVAND experience to trust an editor with this userright. If an editor with 10 years of editing, 3 FAs and 50DYKs applies for this userright, it should not matter if the last AIV report they filed was 5 years ago. We should still trust that they will know what obvious and aggressive vandalism is when they see it. Those who are ideologically opposed to unbundling in any form (I think most of them are admins -:), will not be appeased by any version of this proposal. I believe that those who would want to aim this userright towards the active "vandal fighter" group only are a minority, because the "vandal fighter" group themselves are a minority, and a pretty small one. A great many more editors would like to be able to use this type of userright occasionally, on as needed basis. I think that a secondary selling point of such a proposal, when aimed at a wider pool, is that it would involve a larger number of experienced users in performing actual admin tasks and perhaps induce them to run for RfA later. Of course, that will be a controversial point, and some people will be making exactly the opposite argument. Nsk92 (talk) 00:22, 18 April 2021 (UTC)

Comments by Justiyaya

After skimming through some comments, I think most of them are talking about increasing the limitations to get the role, but I believe more limitations defeats the purpose of this role. Personally, I think we should reduce the power that this role has instead. So that this is more of an upgrade to rollback rights, and not a gigantic leap in responsibility from it. I suggest these changes to the proposal.

1. Blocking can only take place when 2 different extended confirmed users (Can include blocker) have warned the user. Level one warnings doesn't count. This should not be a policy that responders have to try to follow, and instead the software should just reject the person attempting to block if this condition is not met.
2. Blocks last 30 minutes, the 30 minutes are not to deter the vandal, but to give admins time to respond. I believe that probably the most annoying thing about anti vandalism is reporting the vandal to AIV and no one responding, and the goal of the role is not to lessen the load on admins, but to not require admins to respond to the report right away.

If you have any questions, respond here, but remember to ping me. Justiyaya (talk) 16:58, 19 June 2021 (UTC)

Towards an RfC

I can tell people think "place a block while you wait for an admin" is too limiting. Honestly, a lot of blocks for vandalism don't require much judgment. So, one question is whether admins are always expected to re-block IPs that responders block, because admins might think a re-block is pointless. So, I see room for a more heavyweight version, where the block is long enough that a block by a responder is enough to resolve an AIV case. I don't know how long that would be, because I don't think we've ever experimented with short blocks. For example, if an IP is blocked by a responder for only three hours (blantant vandalism, as always), would we expect them to resume vandalism? 31 hours is the current standard, and that works, but of course that's far too long. Maybe six hours?

An RfC would have three options:

• Add a responder role, just for very high-speed (~1 epm) blatant vandalism. Admins would be expected to re-block. Hour-long blocks. (Maybe 15-minute page protection.)
• Add a responder role, for high-speed blatant vandalism. Admins would NOT be expected to re-block. Six-hour blocks. (Maybe hour-long page protection.)
• Do not add a responder role.

Do people think anyone would go for the heavier option? Enterprisey (talk!) 04:56, 20 October 2021 (UTC)

Further ideas: second question of "should protection be included in this", and perhaps limit the trial to at most X people promoted per week or at most X blocks per week (for the first N weeks?) Enterprisey (talk!) 08:17, 10 November 2021 (UTC)

@Enterprisey: I think there is a fundamental issue here, which is the scope of the problem. Based on Wikipedia:Requests_for_adminship/2021_review/Proposals#Closed:_7E_New_"Semi-protector"_role I'd observe that (probably):

• There will be on-principle opposes ('only admins should be able to block', 'if I trust someone with this, I'd trust them at RfA')
• Of editors that would support a variant of this proposal, each variant is sufficiently distinct such that they might oppose every other variant. e.g. some editors might only support this as it is currently (to deal with vandalism while an AIV report is pending), others may say that's useless/not a problem (notwithstanding your data collection). Some might support a "vandal fighter"-like user-right, which allows blocking newer editors for vandalism-reasons only. Some will oppose such a right on-principle (creating classes of editors, new editor retention reasons, alleged higher error percentage, etc.). There could be an IP-only variant of that proposal, which could get support from those concerned with IP vandalism and non-registered editing.

etc... I'm not presently optimistic that a single variant could achieve consensus. It would need to both demonstrate useful purpose (data might help with this, but IMO data will not overcome editor feelings), and somehow overcome all the on-principle objections. I'd personally suggest preparing a FAQ of expected oppose reasons. It might convince at least some editors with hypothetical concerns, if there is a presented reason for why the proponents believe said concern won't realise in practice. ProcrastinatingReader (talk) 17:43, 20 November 2021 (UTC)

I agree with all of that. I think having different options is a solution to the "scope" problem. Enterprisey (talk!) 22:19, 21 November 2021 (UTC)

We talked about this offwiki again

Discussion participants are anonymous (besides me). Summary:

• Explore (again) further restrictions: "has vandalized in the very recent past (10 minutes)"; "all edits reverted in the last hour"; "have gotten to uw4 in the last hour"; "all edits over cluebot rating X.Y in last hour". Setting the time intervals is tricky because this is the AIV stale report problem in a different form: how old does a case have to be before it merits a block? Can the proposal avoid making a ruling on this?
• Key requirement (in my opinion): making it harmless (through strict rules) enough that we could give it out to anyone and/or have a bot take action based on the rules and it wouldn't draw much complaint.
• Precise definition of "more than one per minute": "strictly fewer than 60 seconds between any two of their edits". But how recent must the edits be? (same question as above)
• (Implementation detail, just an idea for the idea book): have a user script highlight "eligible" IPs?
• Oppose reason: high level of gamification of antivandalism, this could make it worse; quantity over quality problem with current antivandalism, lack of effective supervision/oversight/accountability
• If someone doesn't want to go through RfA, why would they go for this?
• Oppose reason: People will be opposed at RfA for the reason that they could just apply for this, thus increasing standards at RfA.
  • Response: This role is an additional utility for people who make reports at AIV, nothing more. This role is so far away from adminship that it would be silly to tell an RfA candidate to get this instead: it doesn't even really help with antivandalism that much. No reasonable RfA voter would use that reason, so in practice RfA's difficulty is not increased.
    • Response: "Silly" (controversial) votes can still swing close RfAs. (Response to that: I trust the crats, I guess?)
• If the role is too limited, it won't pass; if it's too useful, RfA will tell them to get this instead of sysop.
  • "you can't actually fight that much more vandalism with this" - but then what's the point? Well, precisely to avoid page histories that look like this, and nothing more.
• Oppose reason: there is no sweet spot between "we're giving an ability to people who shouldn't have it" and "this will have no meaningful impact"
  • Response: There are tens of thousands of edits annually that can be saved even with the most restrictive ruleset.
    • Response: And vandals won't just wait out the block? (Response to that: Another responder will block them.)
• Action item for me: Re-run the analysis, as recent edit filter work has likely changed the numbers quite a bit.

Thanks to all the participants, Enterprisey (talk!) 10:43, 20 December 2021 (UTC)

@Enterprisey. Is this proposal dead in the water? A shame considering it might have some use for users, and a good alternative considering how stressful RFA can be. CollectiveSolidarity (talk) 15:17, 3 August 2022 (UTC)

@CollectiveSolidarity, thanks for the comment. I had stopped working on it because I was busy with other things, but now I have more time. I still think it's a decent idea. I just made some edits to the proposal and I may start the RfC at some point. Enterprisey (talk!) 06:49, 7 August 2022 (UTC)

Technicalities of blocking

I think some details are missing in this proposal. Can a responder revoke talk page access? Can a responder upgrade a partial block? 0xDeadbeef 13:25, 9 August 2022 (UTC)

Based on what I've read it looks like they cannot revoke TPA but they can upgrade a partial block if the same conditions are met that would be required to block any other user. Personally I think it might be worth considering this just being a blocking bot that does short temporary blocks based on a set of criteria, with no specific action from a responder required, but I'm not sure how well supported that would be. PhantomTech[talk] 20:44, 9 August 2022 (UTC)

I'm pretty sure this idea is going nowhere (we've been talking about it for almost 2 years now), so this is a bit moot. In any case, I can't see any reason a responder would need to revoke TPA. The only reason this role would exist is as a quick emergency response to contain ongoing disruption. If somebody wants to rant on their talk page, it's really not disrupting anything, at least not in a way that requires quick response. -- RoySmith (talk) 23:36, 9 August 2022 (UTC)

Well we gotta take it out of the oven sooner or later. @PhantomTech, I think a human would have to be involved in the blocking process, considering an automated bot might get things wrong. But hey, if you want to try creating ThePhantomBot II with this design in mind, I think it would spark at least some discussion. CollectiveSolidarity (talk) 01:35, 10 August 2022 (UTC)

@deadbeef, clarified re TPA (answer is no), and a partial block would exist independently of any blocks placed with this role (although in practice, if the reported user is already subject to a partial block, I'd expect good judgment to be applied before considering an additional full block). A bot was considered but very few people would support any sort of automatic blocks. This will indeed come out of the oven sooner rather than later... just gotta get another round of feedback I guess. Enterprisey (talk!) 01:48, 10 August 2022 (UTC)

@Enterprisey. I have a suggestion. I think the potential responder should also have rollback for a while before gaining this permission. Just to show that they have the wisdom to properly revert vandalism before moving on to more serious matters such as blocking an actual user. CollectiveSolidarity (talk) 01:53, 10 August 2022 (UTC)

Sure. I revised the guidelines. How's it look? Enterprisey (talk!) 02:14, 10 August 2022 (UTC)

@CollectiveSolidarity I don't mean that some trusted human actions would be completely unnecessary, just that a set of criteria could be made where once a trusted user completes a set of actions that they would have taken regardless of some bot's existence, the bot would put in place a temporary block. As has been pointed out, it may be very unlikely that the community would support blocks that were this automated and the criteria would need a lot of discussion. However, as an example, if:

• A single user (the "reverting user") reverts more then 3 edits by the same user (the "reverted") on a single page
• The reverts are all within a short period of time (30 minutes?)
• The "reverting user" is trusted, either based on being on a list of responders, or some other metric to be determined
• The "reverted" meets some eligibility criteria, such as being a very new account or an IP with less than a certain amount of recent edits
• The edits that were reverted are indicated to be vandalism, some possibilities for determining this are
  • The "reverted" was reported to AIV by any user within the same trusted group as the "reverting user"
  • The revering edit summaries support that they are a vandalism revert

then:

• It is assumed that a user conduct issue has occurred because both users would have violated WP:3RR if there is no valid exemption (it is important to note that the bot may not know which user had a valid exemption or what that exemption was)
• It is assumed that the criteria for trust is sufficient that in almost all cases a trusted user will not have been the problem
• Actions are taken "against" the "reverted" which could be:
  • A temporary block, time determined by expected response time at AIV
  • Temporary page protection, for the first trigger of an action against the specific "reverted" user, a temporary block for any second trigger that occurs before manual review
• A log of the action is posted at AIV where it stays until it is reviewed by an administrator

This would likely need a trial to have any chance of convincing the community, where instead of taking any block or protect action the bot would just log an intent to or something. It has downsides, a process that involves trusted users specifically signaling the bot to block a user, like the current version of the proposal, is probably something that more people will support and is less limited in who it can block. If the process to signal the bot can be easily integrated into current workflows, it is likely the better option. Something like pinging a bot in an AIV report is something I'm sure a lot of people would be willing to make use of when appropriate, needing to use a specific template for the report would likely be used sparingly until it was integrated into current tools like Twinkle. ThePhantomBot can't have much involvement because it is not an admin bot so it would be useless once the bot left the trial phase, but I am working on the bot again :). PhantomTech[talk] 02:36, 10 August 2022 (UTC)

I think your take on the matter is pretty good! We will definitely need a trial need on this. The automated bot would need some easing in to, but I think people will warm up to it if this current proposal passes. CollectiveSolidarity (talk) 02:49, 10 August 2022 (UTC)

Specifics of adminbots assisting responder blocks

An admin bot issues a block to VANDAL_IP as requested by Responder (via OAuth with a toolforge server or a talk page) when all the conditions below are met:

1. Responder is listed in Wikipedia:Responders/list
2. From the block logs, the last block on VANDAL_IP was not made via a request from the Responder (if an admin block occurred since the last responder block, blocking again would be allowed in the case of continued abuse from the IP)
3. Last edit from VANDAL_IP is less than an hour ago.

This does not include checking that the vandalism is actually "high speed," so this part needs judgement from a trusted responder.

When all conditions are met, the bot performs the following actions:

1. Blocks VANDAL_IP for an hour (AO, ACB), with the summary clearly suggesting that a specific responder blocked it.
2. Logs the block at Wikipedia:Responders/log
3. If not already, report VANDAL_IP at WP:AIV.

Feel free to discuss this. I believe a clear set of rules might help this pass. 0xDeadbeef 03:15, 10 August 2022 (UTC)

Current bots will remove the report of a temporarily blocked account from AIV. Personally I think a report should be made by the bot on a page transcluded to AIV requesting an admin review, that admin can then extend the block or unblock a bad block. Also, I don't think that there should be a restriction to only IPs since this would provide an easy bypass for anyone who knows about it in advance. Criteria should be checked for IPs and accounts to attempt to ensure that active editors, whether they edit with an IP or account, cannot be affected.

It may be possible to use historic AIV response time statistics and the number of currently active admins to estimate how long it will take for an admin to review the report and have the block be for somewhere around that period of time instead of a specific set time. There are times when reports at AIV can take hours to be reviewed. PhantomTech[talk] 03:31, 10 August 2022 (UTC)

An IP only restriction was debated a lot of times. The reason for IP only was so that the proposal would have a higher chance of getting accepted. Some examples for the response times are indeed vandals with accounts. 0xDeadbeef 03:41, 10 August 2022 (UTC)

An IP only restriction was debated a lot of times. I didn't realize, thanks for the info. PhantomTech[talk] 03:48, 10 August 2022 (UTC)

Honestly, keeping it to IPs only doesn't really pull its weight. I'll remove it. It doesn't really make sense to have the restriction. Enterprisey (talk!) 06:37, 10 August 2022 (UTC)

Ah, now I remember why - it's unclear where to draw the line. Non-autoconfirmed? Younger than a day? Etc etc. Enterprisey (talk!) 06:46, 10 August 2022 (UTC)

Accounts less than a day old added to the proposal. Enterprisey (talk!) 07:24, 10 August 2022 (UTC)

The rules are pretty similar to the existing wording in the proposal. If you think they'd help more people understand the proposal, I guess we could put them in. Enterprisey (talk!) 07:38, 10 August 2022 (UTC)

I don't think it is necessary to be in the proposal, but perhaps it just needs to be written somewhere so that people worried about implementation wouldn't oppose. 0xDeadbeef 14:05, 10 August 2022 (UTC)

I personally believe the proposal is good to go, it just needs a good timing and some luck. 0xDeadbeef 14:12, 10 August 2022 (UTC)

We should do a 2-phase trial. The first phase won't actually block anybody, just log that a block was requested. Run that for a couple of weeks, and let people audit the log. If most of those look valid, then we can ask to start the phase 2 trial where blocks actually get imposed. And, of course, like all bots, this will have a big red "Shut me off" button that anybody can activate. And the block log messages will include a link back to that page. -- RoySmith (talk) 15:38, 10 August 2022 (UTC)

I agree with a 2-phase trial. If someone wanted to get the data, it would also allow information to be presented about the actual affect any blocks would have had. PhantomTech[talk] 21:57, 10 August 2022 (UTC)

Let’s start the RFC next week. We can keep it open a little longer to see if there are any other comments/concerns that might need to be addressed. CollectiveSolidarity (talk) 23:32, 10 August 2022 (UTC)

In the meantime, wouldn't a pre-RfC poll on this talk page be a good idea? After all, it's difficult to tell whether most would support or oppose this. You could get new ideas from dissatisfied users. Nythar^T.C 23:54, 10 August 2022 (UTC)

Next week is fine unless anyone has objections. 2-phase trial is a good idea; I've added that in. @Nythar, sure, more feedback on the current state of the document following my recent changes sounds like a fine idea. Maybe we could ask WP:VPI. In the meantime, we've done several polls on this talk page over the years (!); between those and the larger RfCs before then, such as the Jan 2015 one, we have lots to look at. My personal prediction, by the way, is it's pretty likely to not pass, and if it does pass, it'll be close. Enterprisey (talk!) 09:54, 11 August 2022 (UTC)

• Two issues related to using an admin bot that you may want to head off:
  1. The general concept that actions made by a bot are the responsibility of that bot's operator. Which in this case would mean that the operator would be WP:ADMINACCOUNT for every single block made, personally. So that would either need to be accepted by the operator, over possibly it could be overcome with a strong RFC showing to build a special exception to the accountability component of the admin policy.
  2. A general principal of our volunteer base is that no editor should ever rely that another editor will do something in the future. This creates a high bus factor. This entire process is being build on the concept that one specific admin will operate their bot indefinitely and reliably.
• — xaosflux ^Talk 10:37, 11 August 2022 (UTC)

  I believe the admin bot is only for the trial and we don't need to get mediawiki support for such a user group right now. I agree with the first point, but given that any admin can halt the trial this doesn't have too much weight. 0xDeadbeef 11:34, 11 August 2022 (UTC)

  @0xDeadbeef: So the trial is conducted using a bot with no actual blocking by the sample group taking place. But it'll work differently later on (presumably no bot). Nythar^T.C 11:54, 11 August 2022 (UTC)

  The second phase of the trial would be an admin bot, or maybe by then there would be a consensus to get it implemented first. The latter is highly unlikely to me. 0xDeadbeef 11:58, 11 August 2022 (UTC)

  Accountability passes to the users with the role except when technical issues occur. I've always understood it that way, but I'll write it in the proposal anyway, and then this can be the RfC you're talking about. Regarding bus factor, yes it's an issue but it shouldn't hold this up; lots of more important things around here have bus factor issues, plus I'll recruit other operators. Enterprisey (talk!) 12:51, 11 August 2022 (UTC)

  Obviously, technical implementation issues would be the responsibility of the operator.

  In general, one can delegate authority to do something but not responsibility.

  The roll up on this is: a block gets made - well it is made by a bot, that bot has an owner, that owner is letting anyone trigger the bot, provided that someone else says the triggering person may. The approving of people to trigger the bot is discretionary (there is only a guideline). So if a bad block is made, who has to answer for it? Only the triggerer? The person who enabled the triggerer? The actual blocker? More than one of these? Explicitly getting support in the RFC for where accountabilities lay can help solve that. — xaosflux ^Talk 13:23, 11 August 2022 (UTC)

  @Xaosflux how's what I wrote? Copy/pasted for convenience: Although it could be argued that ADMINACCT and ADMINBOT would make the adminbots' operators personally accountable for the blocks, if this proposal passes, it is understood that accountability passes entirely to the users requesting blocks, except in instances of bugs and other technical problems with the bot. Enterprisey (talk!) 13:25, 11 August 2022 (UTC)

  @Enterprisey seems good enough. I don't personally love the concept, but this is good in that it both shields the operator and make the accountability very clear. — xaosflux ^Talk 13:42, 11 August 2022 (UTC)

I don't love the implementation

Just some idle comments here, I'm not programming this so feel free to ignore everything :) I don't love that this is going to be driven by trying to put a template somewhere that has to be checked for and processed that way. It seems that for this to work it needs to be "always on", so would rather see a webform. "What if the service is down?" - well then it is going to be broken anyway. Something like:

• Go to responder.toolforge.org
• Logon with OAUTH
  • Users that are on the checkpage (which the server could periodically sync); which are not actively blocked get authorized
    • Get a blocking form (this could be prepopulated with get parameteres from the initial connection) (Who to block, notes)
      • Service makes any validation checks
      • Bot makes the bot, putting information about the block in to the block log
    • Get an optional unblock form, can only be used to revert a block you made
• I'd much rather this be an extension do this server-side Special:Responderblock or whatnot, but that's another story. — xaosflux ^Talk 13:52, 11 August 2022 (UTC)

I didn't put much thought into an admin bot looking for template transclusions on the AIV page, but I know it will be complicated and as you said, requires continuously running the bot. The reactive web service is better IMO. But honestly I don't think the participants at the RfC will really care about whether it is a web form or a template. 0xDeadbeef 14:50, 11 August 2022 (UTC)

"Always on" bot processing is straightforward to implement via the Wikimedia EventStreams API. Using a toolforge webservice moves the audit trail away from enwiki, which is not a great idea. – SD0001 (talk) 07:15, 12 August 2022 (UTC)

Either would work and it just depends on what approach the implementer wants to use. 0xDeadbeef 09:30, 12 August 2022 (UTC)

@SD0001 in the scenario above, the "audit trail" of what, putting some wikitext somewhere? I don't love that after this everyone else has to then wait and watch for the bot to come along in what is meant to be a very urgent situation.

If depending on wiki text, I suppose I'd want the bot to link to the specific diff in the block log; something like :

(Blocking on behalf of User:SD0001 per request, $REASON)

— xaosflux ^Talk 12:56, 12 August 2022 (UTC)

Yes. The bot would be able to react in 3 to 5 seconds if it uses EventStreams, which seems fast enough to me. A diff is a reliable way of recording that someone requested something, which won't be there if it's a webservice (what happens if the bot starts making blocks on behalf of someone but that someone claims they didn't trigger the bot?). Also it's easier to implement than an OAuth tool. – SD0001 (talk) 14:25, 12 August 2022 (UTC)

We could also require an edit to be made, and then have a page on toolforge that anyone can use to make the bot check for edits (in addition to eventstreams and/or polling). Like SD0001, I find having an onwiki audit trail a compelling benefit. Enterprisey (talk!) 14:53, 12 August 2022 (UTC)

Protection vs blocking

@Enterprisey, regarding Special:Diff/1103912115, I would prefer to see that phrased differently. We don't want to imply that that page protection is the generally preferred option. It's something that's resorted to only when blocking has been shown to be ineffective. WP:PP says, Pages are protected when a specific damaging event has been identified that can not be prevented through other means such as a block. At SPI, I'll often protect a page and suggest to the filer that they should use WP:RFPP if the problem persists. But it's not that I feel a block would be inappropriate. It's more that block(s) would ineffective in this case and RFPP can move faster than SPI does. -- RoySmith (talk) 15:56, 11 August 2022 (UTC)

Excuse me butting in, but I believe that historically one of the objections to unbundling blocking has been that users with the ability to block but not protect will be predisposed to blocking when protection is the appropriate option (To a man with a hammer, etc). As such I do think the phrasing on this page should delineate quite firmly when folks with this userright should defer (or refer to) RFPP. Vanamonde (Talk) 20:12, 11 August 2022 (UTC)

@Vanamonde93 I think this is a fair point. Perhaps if there are three or more users causing disruption on a page, protection would be the appropriate option. Perhaps this is a good solution? CollectiveSolidarity (talk) 00:23, 12 August 2022 (UTC)

I'd slightly prefer making the principle clear without setting a hard boundary. The point is that it's situational; there's a substantial grey area that's hard to delineate a priori. Vanamonde (Talk) 16:07, 12 August 2022 (UTC)

I agree with Vanamonde. Blocking shouldn't be done when protection would be more appropriate. 0xDeadbeef 01:48, 12 August 2022 (UTC)

• I just want to note that my original comment was a bit of a nit-pick. While I'd be happy to see improved wording, it's not such a big issue that I would want to see a RFC or trial held up pending its resolution. -- RoySmith (talk) 16:41, 12 August 2022 (UTC)

  I don't really see much of a distinction between "inappropriate" and "ineffective", but I would be happy to add clarification if needed. I think the existing example, of a page being disrupted by many users, is pretty illustrative. Enterprisey (talk!) 15:54, 17 August 2022 (UTC)

  Inappropriate implies to me, "against policy", while ineffective just means, "unlikely to do any good". -- RoySmith (talk) 15:59, 17 August 2022 (UTC)

  Sounds good. I changed it to "ineffective". Enterprisey (talk!) 04:20, 26 August 2022 (UTC)

Thoughts from Ritchie333

I've read through this proposal, and I'm a little surprised that AIV is that backlogged. I've had a look over the past day or two, and generally only seen 1-2 editors that can be blocked easily. I'm also concerned about the following scenario, which while not frequent, has the possibility of blowing up:

1. An IP blanks something seemingly reliably sourced in a BLP
2. An experienced editor puts it back
3. The sequence of 1) and 2) repeats a few times
4. Another editor puts a report on AIV (they should have gone to AN3 or ANI, but hey - users are not obliged to memorise policy)
5. A responder sees "revert", "revert", "revert" for no reason, remembers this, puts 2 and 2 together to get 5, and blocks the IP
6. After an angry rant on the IP's talk page about "Wikipedia putting up libel for no reason", the responder asks for a NLT block on ANI
7. I see the report, and think - woah, can we all, like just calm down a bit, you know......

I think my problem is that no administrator would do this, because the scrutiny at RfA is such that you wouldn't pass unless you knew and had experience of all of this. But the responder role won't have that level of detail, so mistakes will be made. The question is - how can we avoid them, and what do we do about them?

In particular, I personally would like to adhere to User:Ritchie333/Why admins should create content (though I realise not everyone would) when assigning this role - in a nutshell, I want people to look at the content of what is under dispute, don't just block because of the username or who they're reverting. Ritchie333 ^{(talk) (cont)} 14:23, 12 August 2022 (UTC)

An edit war is an interesting case, because it may or may not be vandalism. Responders aren't AIV clerks in this sense and should be able to judge what constitutes vandalism. In my opinion, responders should stay away from controversial edit wars as much as possible, except for cases where the users will obviously end up getting indeffed or IPs end up getting their standard durations. For example, if I, as a hypothetical responder sees this, and noticing the sock puppetry, I would block. 0xDeadbeef 14:59, 12 August 2022 (UTC)

I certainly endorse an indef block for Rikmayallfanclub (talk · contribs), but for tendentious editing. Unless the SPI shows this is proven habitual behaviour known to be in bad faith, in which case I think it's beyond the pay grade of a responder, which should only deal with blatant and obvious vandalism - after all, there's a whole bunch of people out there who really do think Donald Trump is the best person to lead America, and they're not saying in bad faith. Ritchie333 ^{(talk) (cont)} 16:12, 12 August 2022 (UTC)

That's certainly a potential problem. Thanks for identifying it. I agree this role should only be for blatant and obvious vandalism, and I've clarified what "blatant" means in the text of the proposal (pasted here for convenience: there must be no way it could be good-faith editing. In particular, it must not be mere tendentious editing or edit warring). I suppose that might not really solve the problem, though. Are there more potential situations like this, or can we just put "see WP:DOLT" in the guidelines? Maybe we should further mitigate this through an appeals process? If we assume an admin will individually review each block, the risk goes down, but I suppose it would be safer to not make that assumption. Enterprisey (talk!) 16:36, 13 August 2022 (UTC)

If we assume an admin will individually review each block, the risk goes down, but I suppose it would be safer to not make that assumption. But isn't "admins will review each block" the point of responder blocks? They are meant to be preventative for high speed vandalism. Looking at it again, a responder shouldn't block the sock I mentioned above because that would violate the "vandalism only" rule. But I think there is also the risk of appointed responders trying to be helpful but violating the rule, which might be something that will inspire the post-trial discussions. 0xDeadbeef 17:00, 13 August 2022 (UTC)

Far in the future, it may turn out that an hour is all that's needed (i.e. no additional admin action is needed), so making admins review each one would be needless make-work. In such a context, Ritchie333's situation may not be noticed. Enterprisey (talk!) 01:38, 14 August 2022 (UTC)

Alright, I think the mitigation here will ultimately be that admins review each block by hand. Enterprisey (talk!) 15:52, 17 August 2022 (UTC)

On Granting this user right

There are a number of things I would like clarified:

1. Wikipedia:Requests_for_comment/Responder_role#Granting states "Editors may apply at WP:PERM. The discussion must be announced at WP:AN and be left open for a minimum of 48 hours." Is this intended to resemble an RfC? And who can vote?

2. Also, for example, if I don't regularly visit WP:AN, how would I be informed of such a vote taking place? RfA's, for example, normally appear at the top of the Watchlist. Or perhaps those interested in voting in future requests could have messages directly sent to their talk pages, per subscription.

3. "a minimum of 48 hours" on WP:AN is not specific. RfA's are set at 1 week (I think), so this could hypothetically stretch on much longer than 48 hours. Could this be more specific?

Thanks. Nythar^T.C 02:08, 14 August 2022 (UTC)

@Nythar

1. I presume it will be similar to applications for edit filter helper at the WP:EFN. Any user can discuss the user's contributions, and !vote support/oppose/neutral based on the candidate's behavior.

2. The discussion will also be announced at WP:PERM, but I don’t think the discussion will be nearly as big as an RFA.

3. My guess this will stretch between 48 hours to 1 week, similar to EFH discussions. CollectiveSolidarity (talk) 17:33, 15 August 2022 (UTC)

Clarified that any user can comment (WP:INTADMIN style). Also clarified that we can set up a massmessage list if desired. A minimum of 48 hours is just what it says; I don't see the need to set a cap. If that seems like a bad idea, let me know. Enterprisey (talk!) 15:52, 17 August 2022 (UTC)

Start the RfC?

Should we give this a bit more time, or is this ready to go next UTC day? @Enterprisey: after reading the RfC draft again, can we change the wording "trial" in the lead to emphasize a two-phase trial? I would also suggest specifying what options are there to vote on (could people support the idea of the trial without requiring another extensive discussion after phase 1 ends? There would be people who would support phase 1 but needs to see evidence that this is a good idea before moving on the phase 2, and these two kinds of people would vote differently) 0xDeadbeef 12:18, 17 August 2022 (UTC)

We've been bikeshedding for way too long. Put it out there and see if it flies. -- RoySmith (talk) 14:06, 17 August 2022 (UTC)

Fine with starting it soonish but not tomorrow. In order to comply with RFCNEUTRAL, we should have a separate neutral summary, which I've started, and also a separate list of common answers to put in the first voter's comment, which I've also started. We can just link to the proposal page at the end of the summary. Enterprisey (talk!) 17:01, 17 August 2022 (UTC)

Is next week alright? Just to give time for any last-minute concerns. It’s probably better to launch it soon or else it will probably fizzle out. CollectiveSolidarity (talk) 22:08, 17 August 2022 (UTC)

I also would like to have this start as soon as possible, but I think we want to put the strongest proposal we can possibly write before the community. Concretely, finishing up the Q&A bit is probably the last thing remaining, because I can't see anything else unresolved on this talk page, and I don't really feel like doing the rest of the analysis. So after that's done, I guess. Enterprisey (talk!) 23:15, 17 August 2022 (UTC)

Renamed from "Comments" to "Start the RfC?" Enterprisey (talk!) 17:56, 17 August 2022 (UTC)

Any admin can halt the trial at any time

To me, this text sounds like any admin can pull the plug on the trial even if community-wide consensus supports it. I suspect what this text is meant to say is that any admin can pull this flag from any user during the trial, but perhaps I'm wrong.

While we're on the topic, I think the "Unless there are any objections" piece of that section needs rewording also; we will have objections, beyond any doubt. Vanamonde (Talk) 15:42, 17 August 2022 (UTC)

The intent is as it reads, that any admin can pull the plug. The hope was the community would be more willing to vote for it that way. It does have undesirable implications; I'd be fine with tossing it.

As for the "objections" part, heh, I'd just deleted that part. What objections do you think people will have? I was thinking it would just be about bad blocks. @0xDeadbeef, let's talk about the trial in this section. Enterprisey (talk!) 15:50, 17 August 2022 (UTC)

I do think we should allow any admin to remove the flag from any individual user, but not to halt the trial at any time; I think an emergency shutoff for the blocks should take the form of conditions under which the bot may be blocked (which presumably exists; you would know better than I) but an emergency shuttoff for the proposal itself doesn't strike me as very necessary.

re: objections; honestly, I simply mean there will be objections because this is Wikipedia and there's always somebody who objects to everything. Vanamonde (Talk) 16:50, 17 August 2022 (UTC)

There should certainly be a "break glass" function where any admin can pause the trial if they think the bot has gone crazy or there's obvious abuse going on, or something like that. But that's just to give somebody a chance to look at the problem and fix the code (or kick somebody off the island). It shouldn't be "I'm opposed to this whole idea so I'm blackballing the trial". -- RoySmith (talk) 17:00, 17 August 2022 (UTC)

Surely BOTPOL allows us (admins) to block the bot if it goes haywire, without making it a part of the proposal? Vanamonde (Talk) 17:06, 17 August 2022 (UTC)

100% any malfunctioning bot can be blocked by policy, this wouldn't override that. The "trial" would still be going on, it just would be toothless. — xaosflux ^Talk 17:51, 17 August 2022 (UTC)

Blocking would be for technical issues and malfunctioning, a pause (which is a better idea, thanks for suggesting it, I'll put that in) would be "I don't like the blocks people are making" or something like that. Enterprisey (talk!) 17:56, 17 August 2022 (UTC)

Trial, again

I realized that the 2-week trial might not be possible to implement because we might not get anyone in the role in that time. Also, it's weird that only the first users who get in the role are subject to a trial, and everyone else gets to immediately start blocking. Thus, I made a few changes: every user who applies for the role gets their own 2-week trial, the first phase was removed, and the 3-month timer for the trial only starts after the first user gets the role. @RoySmith, you proposed the 2-week trial originally; is this OK? @PhantomTech, you also agreed with the trial. Enterprisey (talk!) 04:14, 25 August 2022 (UTC)

Seems like a better idea. 0xDeadbeef 05:01, 25 August 2022 (UTC)

An alternative could be to come up with a group of trial participants, these pre-selected users could all get the role at the start of the trial to enable it. However, I don't have a problem with the change. It should probably be specified that candidates should log their intended blocks on-wiki and at the time they would have requested the block. PhantomTech[talk] 05:23, 25 August 2022 (UTC)

I don't think a trial is needed for each individual user. In my mind, the trial period was to prove the concept, not the people. But, I'm not opposed to it. I fear we're getting into analysis paralysis territory. -- RoySmith (talk) 12:33, 25 August 2022 (UTC)

Yeah. The primary focus I believe is the neutral summary and the Q&A mentioned above. 0xDeadbeef 14:14, 25 August 2022 (UTC)

Alright, I think the summary and Q&A are done, except maybe we could add a bullet for "the bad blocks will only come 6-12 months in", to which I don't have a good response, except to say it sounds like pessimism that I don't see a good reason for. How's next week? Enterprisey (talk!) 04:29, 26 August 2022 (UTC)

Sure. Thanks for the improvements. 0xDeadbeef 14:08, 26 August 2022 (UTC)

I reread the "vandal fighter" oppose section (a highly recommended activity) and my main takeaway is we'd better have a good answer for "people will make bad blocks with this" / "only someone with admin-level judgment can be actually trusted to make these blocks, despite trying to structure the role to make it easier". Here's a wild idea: replace the ">1 edit/min" requirement with something like "they've made five or more edits that are vandalism in quick succession". I'd have to run the numbers to see if that would actually address the problem, though. Enterprisey (talk!) 05:29, 28 August 2022 (UTC)

people will make bad blocks with this

1. A purpose of a trial is to see if this is what actually ends up happening or not
2. The current proposal requires people to demonstrate that they would use the role correctly before being granted it
3. Blocks will be reviewed and bad blocks undone
4. People who make too many (by whatever metric) bad blocks can have the role removed by any admin, a single admin being convinced the user isn't able to make good blocks is enough for them to lose it
5. The current proposal, in my opinion, heavily restricts who can be blocked to the point that I believe an extremely similar set of criteria could be fully automated and result in few bad blocks, or at least a very low percentage. Adding a human review (the users with this role) should be enough to lower bad blocks to an acceptable level. RfA or not, no one is completely immune from making bad blocks but again, these requirements are so limiting a bot could probably do well with them.
6. Hopefully having some statistics will be helpful for convincing people

only someone with admin-level judgment can be actually trusted to make these blocks

I saw in the opposes of the proposal you linked the idea that someone who has the judgement to make a block should just become an admin. I'm not sure how prevalent that idea is now but I don't think that an RfA for someone who primarily does vandalism work, with little or no content work, would pass even if they had a perfect AIV record, despite that being direct evidence that blocks they made would be justified. For this proposal, I don't have a problem with either the ">1 edit/min" requirement or "they've made five or more edits that are vandalism in quick succession", though people may want a specific time period for "quick succession". PhantomTech[talk] 09:35, 28 August 2022 (UTC)

I’d suggest that "In quick succession" would be at least five vandalism edits within 5–8 minutes. In regards to Admin-level judgement, someone who is good at making AIV reports will not automatically show clear judgement in other admin-ny areas such as CSDs. This right is just a way to help out especially good vandal fighters who can have their blocks reviewed by experienced admins. Also, since the community would be taking an active role in granting the right, there will be plenty of people examining a candidate's contributions and making sure that they will have the judgement to not make bad blocks. CollectiveSolidarity (talk) 02:25, 29 August 2022 (UTC)

I agree that good AIV reports are not necessarily an indicator of being able to handle CSDs or other admin tasks unrelated to blocks, but the argument that some people seemed to be making in the "vandal fighter" opposes seemed to be that if an editor can be trusted to make good blocks then an RfA from them would pass and that RfA is the path for those editors to be able to make blocks.

Separately, I think expectations of RfA candidates are too high and that is part of what creates a need for a proposal like this. A hypothetical editor with a significant and perfect AIV record certainly shouldn't automatically be assumed to be capable of handling anything else, including CSDs, but likely (hopefully likely, maybe I'm being too optimistic) has the self awareness to know that they shouldn't carelessly jump into areas they lack experience. The hypothetical editor's AIV record would be very strong evidence that they can be trusted to decide when a block is appropriate. There's more to making blocks than just deciding if they're appropriate but in the example there'd likely also be enough evidence to evaluate related things like how the hypothetical editor interacts with other editors. My assumption would be that an RfA by this hypothetical editor would fail. If they indicated in their RfA that they planned on doing something unrelated to AIV, then this would likely be understandable. If they are running to be able to continue what they'd done previously and skip needing to report users to AIV or if they'd like to act on AIV reports, then it seems like a failed RfA just prevents a reduction of AIV workload for other admins. I may be wrong but it seems some !voters at RfA have certain tasks that they expect an administrator to be able to do, even if a candidate has no interest in that task. If that's the case, all it does is prevent editors who are capable of doing some admin tasks, and not interested in others, from handling those tasks and causes others to try to come up with proposals like this one to try to find a way for those editors to do tasks they're competent enough to do. PhantomTech[talk] 03:15, 29 August 2022 (UTC)

I agree with this, but it appears to me that there will be another issue about this proposal: !voter perceptions about who should get the administrative tools, especially the block button. My perception is that some !voters are very worried about tool misuse, and as such they typically support candidates who have near-perfect records in multiple areas. Now, there's nothing necessarily wrong with keeping the Admin Corps populated by the "best of the best", but there are very few people that can meet that high standard. As such, many vandal fighters will not have the experience in multiple areas to gain the tools just to help out with vandalism. Although the Responder could potentially help out a little with AIV, there are inevitably going to be some opposes along the lines of "tool misuse". But tool misuse is going to be inevitable, and this is a substantially weaker tool than a hard block. If the (potential) Responder candidate passes the scrutiny of other editors at AN and starts making bad blocks, the role can be easily taken away and the blocks will probably go out quickly. The Responder role is certainly more powerful than other tools like Rollback, but nowhere near as dangerous as the administrative toolset. In other words, if the candidate starts biting newcomers with blocks even after a community inspection, the mess can be potentially salvaged considering the block does not last long. So yeah, this tool could be an asset to those not meeting the standards for an admin, but have enough clue to make good decisions around vandalism. CollectiveSolidarity (talk) 22:25, 29 August 2022 (UTC)

I think that all that can really be done to alleviate the misuse concerns is to remind people that both granting and use of the tool will be scrutinized, and that people can misuse anything. The only way to avoid misuse is to not allow anyone to do anything. Misuse, or the possibility of it, does not necessarily mean something is not a net benefit to the project. There needs to be a willingness to figure out where exactly misuse becomes prevalent enough to become problematic, otherwise we are just holding back beneficial changes out of fear. While we shouldn't try something like giving all user's access to the block right to see how it goes, I think this proposal is an extremely limited expansion on blocking abilities, hopefully people will agree and be willing to take the risk. PhantomTech[talk] 00:09, 30 August 2022 (UTC)

Thank you both for your comments on that. After some more chatting, I now agree with RoySmith above that we're probably at the point of diminishing returns. I will run some more queries on the data to see if "5 edits in 5 minutes" would still reduce the total number of problematic edits by an acceptable amount, make any appropriate changes to the RfC, and then put it up. For venue, I'm thinking votes go here on this talk page (after we archive the current contents), proposal stays where it is, and we put hatnotes on VPR, VPP, and CENT? Enterprisey (talk!) 23:11, 29 August 2022 (UTC)

@Enterprisey Works for me. CollectiveSolidarity (talk) 23:16, 29 August 2022 (UTC)

Suggestions

My preferences are for:

• 3 or 6 hour blocks instead of 1-hour. AIV reports often sit for well over an hour.
• Prohibit serial blocks by responders  – ie, none of the If not, another responder can handle it. The understanding should be that the only way a responder block gets extended through sysop action.

Best, KevinL (aka L235 · t · c) 23:16, 29 August 2022 (UTC)

Sorry for the last minute suggestions, but maybe these would be better as amendments? The current proposal would keep 1 hr blocks, but be changed to not allow any sequential responder blocks. There would then be two more subsections of the proposal:

1. If the main proposal passes, temporary blocks are instead X hours in length
   • Support
   • Oppose
   • Discussion
2. If the main proposal passes, a user who's block expires can be blocked by a different responder if the same blocking conditions are met
   • Support
   • Oppose
   • Discussion

I'm not sure if that would overcomplicate the proposal, but it might give the proposal a better chance of passing in some form if there isn't consensus for parts of it like the block length. PhantomTech[talk] 00:24, 30 August 2022 (UTC)

Your second suggestion is good, and I've adopted it. The problem with longer blocks is it makes the role more powerful and it's more annoying to sit out a 3-hour bad block. From the 2020 graphs, the median AIV report always gets resolved within an hour and the mean report almost always gets resolved within an hour. Enterprisey (talk!) 02:22, 30 August 2022 (UTC)

@Enterprisey @PhantomTech. Is September 3rd alright? I think the proposal is as good as it ever will be. The discussion here is lukewarm, so I don't think there are any glaring issues to speak of and resolve. Put it out there and see how well it does. CollectiveSolidarity (talk) 02:19, 2 September 2022 (UTC)

I don't have a problem with September 3rd. PhantomTech[talk] 04:17, 2 September 2022 (UTC)

Maybe not quite yet - I haven't run the queries yet. Was actually setting up to do that just now. Might be another few days. My weekend's looking wide open, so the odds are good that I actually do it this time. Enterprisey (talk!) 01:02, 3 September 2022 (UTC)

Ok, I ran the numbers and it turns out any sort of hard restriction is useless; I'd previously been way overestimating the number of edits that would be saved. Turns out "2 edits in 2 minutes" only prevents ~1000-2000 edits, not the 6000 previously conjectured, and it gets worse from there; by "5 edits in 5 minutes", it's in the ~800 range. I've replaced it with a requirement for "rapid - approx 1/min" editing. The analysis code has been updated so it should be much easier to run.

Maybe next up we ping a couple of opposers from the vandal fighter rfc? Would that just be stalling? We do need to trim a little fat from the RfC, though. Enterprisey (talk!) 06:18, 3 September 2022 (UTC)

Are we going to get much feedback by doing so other than just "I don't like this"? 0xDeadbeef 07:37, 3 September 2022 (UTC)

The only opposer that I can think of contacting would be Beeblebrox, since he was involved in the vandal fighter rfc and a limited block RfC from 2013. But at this point the proposal probably can’t get any more refined. I think people might give the trial a chance, and the kinks can always be worked out through later discussion. Let's just put it out there, and not let this smolder for too much longer. CollectiveSolidarity (talk) 21:47, 3 September 2022 (UTC)

I would prefer to keep going until there's truly nothing else left to improve. The proposal has greatly improved just in the past month, and we realistically only have one shot at this. It shouldn't be much longer, though. Maybe one last VPIL discussion. Beebs' input below is very helpful. Enterprisey (talk!) 05:18, 8 September 2022 (UTC)

Update, for posterity, I was wrong about the overestimation but I'll keep the relevant part of the proposal as-is. Enterprisey (talk!) 01:29, 6 September 2022 (UTC)

concerns

First off, let me say that this is one of the better unbundling proposals I've seen come along, it's clear that a lot of thought went into it and I will not be issuing my usual generic oppose statement about giving someone all the tools or none of them. However I do have some concerns:

• WP:PERM is not set up as a discussion venue. Or at least not a "widely advertised" discussion venue. Currently all pages there work basically the same, a user makes a request, a single admin responds and evaluates the request. The few discussions that do have substantive discussion tend to get neglected. So, if we're inviting more commentary for this user right it may need a bit more structure than the typical PERM page. (but, for the love of Jimbo, no bolded !votes please)
• 1,000 edits trikes me as a little low to consider handing out the block button, that may be a sticking point going forward. 2,000 seems more reasonable as that is usually going to be a few months of experience and if they show poor judgement when vandal fighting it should be very evident by then.
• Use of the rollback tool should not be an explicit requirement, unless it also made explicit that using the rollback feature in Twinkle or similar tools is the same thing. (I personally think Twinkle's rollback functionality is vastly superior, and also don't want to create a ladder of admin prerequisites that must start with rollback.
• "Should the ability to briefly (15 min?) protect pages be added?" No, a thousand times no. Blocking only effects one user, protection can effect hundreds or more. Also, aiming too high is a great way to doom the entire proposal.
• Crusty old users like myself are still gun-shy about trials of new user rights, due to the years-long debacle following the pending changes trial. See WP:PCRFC for just the most basic information on the amount of time and effort this took. The main reasons it was such a morass were:

• It was not made clear in advance if, when the trial period concluded, the right would by default remain in use or be shut off until a final decision was made. This became a HUGE sticking point in later discussions and arguably delayed a final decision by about a year.
• It was not made clear, ever, to this day, who was supposed to be collecting , presenting, or analyzing data to be used to evaluate the trial. Therefore, nobody did and we had a trial period but no actual results of that trial.
• It was not made clear in advance what process would be used following the trial to make a decision on permanent implementation. I eventually invented a new type of RFC framework (that was only used that one time, as a sort of emergency measure) to force a useable result one way or another., and we still weren't done for a few more years. This may be less of an issue here, if the previous points are addressed.

• I think it should be made clear that failure to already have the two-week log in place and ready when the request is opened is an automatic fail, no discussion required, anyone can just close it as failed.

Beeblebrox (talk) 17:51, 7 September 2022 (UTC)

1. That's a fair point. We can start designing a venue when we get a chance.

2. I agree with this. Semi-automated editing especially with vandalism tends to inflate edit counts. I'd personally raise the requirement towards 3,000 edits, but 2,000 is a bit more obtainable.

3. I'll reword it to include Twinkle/UV/Redwarn.

4. I didn't expect many people to support this anyway. It would cause way too much collateral damage.

5a. Probably be shut-off until the final decision is made. To avoid the potential for collateral damage of course.

5b. I think Enterprisey will help with collecting the data. He did the vandalism tests earlier, and so it would be natural that he would manage the trial. A group of volunteers would help with analyzing the results.

5c. Your RFC handiwork might come in handy. I'll take a look at that.

6. Noted.

Thanks for your input Beeblebrox. We'll start working on these things. CollectiveSolidarity (talk) 18:12, 7 September 2022 (UTC)

For 5a, I agree that at the end of the trial the role should be stopped. Consensus for a trial is not consensus for permanent/indefinite implementation after the trial unless that's explicitly stated. To avoid any confusion the proposal should explicitly state that it is a proposal only for the trial period. For 5b, I don't think the proposal needs to make clear who will analyze the data. Anyone can collect data after the trial and do whatever they want with it, presumably whoever makes a proposal for a more permanent implementation will have analyzed the data and will present it as part of the proposal. PhantomTech[talk] 20:59, 7 September 2022 (UTC)

Comment regarding 1. I suggest that the venue should not be at WP:PERM and should instead be something more like WP:AFC or WP:EFN. The discussions could be made at Wikipedia talk:Responder/List, the talk page of the hypothetical whitelisted Responders page available at Wikipedia:Responder/List. After the request is made on the page, the request can be transcluded to AN or some other venue to alert visitors that the discussion is going on. That should attract more than enough necessary commentary. CollectiveSolidarity (talk) 02:20, 8 September 2022 (UTC)

Some rewording done. I put the venue at AN. Might be a mistake? Maybe the right call? I also encouraged "threaded discussion", which might be unpopular, but "no bolded !votes" would probably go over poorly. Enterprisey (talk!) 20:00, 10 September 2022 (UTC)

@Enterprisey I agree we should try WP:VPIL one more time. CollectiveSolidarity (talk) 22:34, 10 September 2022 (UTC)

Posted there. I've also drafted the actual discussion page (this talk page will be archived and it will be moved here). I wonder if separate Support/Oppose sections are better. I know it makes it easier to check the progress of the discussion, but that's not the most important thing to optimize for :) Enterprisey (talk!) 04:24, 11 September 2022 (UTC)

I agree. It is better to encourage discussion rather than have a Support/Oppose CollectiveSolidarity (talk) 21:17, 11 September 2022 (UTC)

Discussion looks a little quiet at the VPIL post. Is there anyone else that we should ask input from? I checked back at the Vandal Fighter oppose section, and there are a few people that might be willing to give a response. CollectiveSolidarity (talk) 00:40, 13 September 2022 (UTC)

Noting, the Vandal Fighter RfC is at Wikipedia:Village pump (proposals)/Archive 120#Proposed user right: Vandal fighter, and people in the oppose section include Jayron32, Robert McClenon, Kudpung, Guerillero, MusikAnimal, Kusma among others. 0xDeadbeef 02:33, 15 September 2022 (UTC)

For the sixth point, as a recent change patroller myself, I notice that a two week period might actually be quite short to actually find users doing high-speed vandalism. This might be an issue with my time zone, but I think it is likely that some people who go through the two-week trial might have no logged actions at all at the end. 0xDeadbeef 04:33, 11 September 2022 (UTC)

The data shows about 12 cases a week of 10+ edits while at AIV, so I think there'll be at least something. It's not a problem if existing responders snap everything up, because the trial just requires logging. Now, if people can't find anything because they don't want to spend excessive time looking (and/or there are time zone issues, like you're saying), I dunno. Presumably that means they won't find anything as a responder? But I'm sympathetic to the issue. We could do a BRFA-style "2 weeks or 10 actions, whichever comes first"? Enterprisey (talk!) 06:19, 11 September 2022 (UTC)

A probationary period with a limit of logged actions sounds good. In addition to RCP, I think it might be easier to find reports in WP:AIV and deciding if a responder block is warranted. 0xDeadbeef 06:24, 11 September 2022 (UTC)

Amended to 2 weeks or 10 actions. I don't think we need to specify where they would find blocks to make, but I would be open to doing so if it's needed. Enterprisey (talk!) 01:19, 13 September 2022 (UTC)

Another suggestion would be to traverse through the history of AIV and manually gather users that could have been blocked by responders into a list and note down the AIV response time for each. 0xDeadbeef 15:45, 11 September 2022 (UTC)

That would be a lot of time. Maybe someone else could do it :) Enterprisey (talk!) 01:19, 13 September 2022 (UTC)

The RfC essay is at User:Beeblebrox/The perfect policy proposal, which I just read. It is a great essay, and I do not see any major problems with this RfC listed there other than people simply disagreeing that this is a good idea. 0xDeadbeef 02:07, 15 September 2022 (UTC)

Another wacky idea: anyone can undo the blocks

Any autoconfirmed user, that is. Thoughts? This would give the community more control over the blocks. And if any reasonable community member would do the unblock, or if reasonable community members would disagree over whether a particular block was needed, the block definitely shouldn't have been made. (Inspired by a 2013 comment by JzG.) Enterprisey (talk!) 01:21, 13 September 2022 (UTC)

I think this could be a decent alternative proposal to be used in case people are anxious about this, but would prefer to keep it out of the main proposal unless it's needed. Best, KevinL (aka L235 · t · c) 01:39, 13 September 2022 (UTC)

It is intriguing, but it could be the target for gaming the system. Say, an autoconfirmed sock of a blocked editor unblocks the first account, leaving two accounts to vandalize while the Responder has decided to move on. Might create some confusion and unnecessary trouble. Perhaps something to think over later. CollectiveSolidarity (talk) 02:12, 13 September 2022 (UTC)

@L235, what about extended-confirmed editors, as Certes suggested? Is your chief concern the potential for drama or something else? If drama, I think the mitigation is the blocks here ought to be really uncontroversial. Enterprisey (talk!) 01:56, 14 September 2022 (UTC)

Alternatively, let any responder unblock. This matches how any admin can technically undo a normal block, but with different etiquette: it might be considered perfectly proper for another responder (or an admin, of course) to reverse a responder block. It seems logical, practical and elegant to grant the block and unblock privileges to the same people. Certes (talk) 22:36, 14 September 2022 (UTC)

This sounds like a good idea which should reverse most bad blocks, but perhaps allow only extended-confirmed editors to unblock rather than any four-day ten-edit sock. On the other hand, anyone blocked in error need only wait an hour (though they probably won't discover that if they're on mobile or IPv6). Certes (talk) 10:46, 13 September 2022 (UTC)

I'm gonna go with extendedconfirmed. Enterprisey (talk!) 22:30, 26 September 2022 (UTC)

@The Night Watch, can you explain why people might oppose over this? I'm ready to believe they might, but I can't think of any concrete reason why. Enterprisey (talk!) 06:06, 28 September 2022 (UTC)

@Enterprisey Although in most cases I agree it would increase accountability, I think this it would cause objection over

1. It gives more authority to users who have been around longer and made more edits, which is something people have been concerned about for a while.

2. It creates the possibility for more slip-ups. I've seen several EC users making bad AIV reports, so why wouldn't they make bad unblocks too?

3. People would put trust into the Responder for their judgement, but they might not trust an ECU to make the same good call.

Basically, it might alienate a few RfC participants, and may cause more mistakes than need be. However, I do agree that any Responder can overturn another Responder's block, similar to PageTriage at NPP. ‡ Night Watch ω (talk) 13:20, 28 September 2022 (UTC)

As the fool who suggested any EC might unblock, I agree that granting unblock to responders only is preferable. Certes (talk) 13:30, 28 September 2022 (UTC)

Changed to responders only. Guess I'm outvoted :) Enterprisey (talk!) 22:50, 28 September 2022 (UTC)

Needed clarification (this vs RfA)

I would think we want a darned good answer to "what would an editor look like who qualified for this but not RfA". Enterprisey (talk!) 01:28, 13 September 2022 (UTC)

I think the classic answer is that the community expects quite a lot from RfA candidates these days because administrators in practice take on many responsibilities that deeply affect the editing experience of community members, including just by wielding their social capital. So RfA voters often demand that candidates have substantial content creation experience, which many of the folks seeking the responder role would not be interested in obtaining. Best, KevinL (aka L235 · t · c) 01:38, 13 September 2022 (UTC)

I think L235's answer is a good one. Aside from that, the Responder role is heavily limited in what it can do, and will only be used for vandalism. Because of this, the level of required experience will be much lower, as all it takes is a reliable sense of what is high-speed vandalism and what is not. Oh, and also a decent temperament that isn’t prone to edit-warring, because that is probably going to be one of the few areas of possible abuse. But since it is going to be handed out after a community inspection, it will probably be unlikely that a chronic edit-warrior will be given the tool. CollectiveSolidarity (talk) 13:13, 13 September 2022 (UTC)

Can we not do this again

If you want the tools, apply for RFA. Can we please stop trying to dodge RFA...

"But RFA is too hard".

Be better then.

"But I don't want to do what RFA expects me to do to be an Admin"

Then you don't get to be an Admin. --Jayron32 17:44, 23 September 2022 (UTC)

Wikipedia desperately needs more people doing admin tasks. There are plenty of good editors who could be trusted to block vandals but will never pass RfA because they have created fewer than 1000 FAs, were inactive for a week in 2007 or once dropped a piece of litter. The responder role seems like an innovative suggestion for solving this problem. Certes (talk) 20:46, 23 September 2022 (UTC)

"Wikipedia desperately needs more people doing admin tasks.". --Jayron32 11:25, 26 September 2022 (UTC)

There is consensus that RfA has too few candidates in 2021. Whether or not that implies "Wikipedia needs more admins", and whether or not that implies "Wikipedia needs more people doing admin tasks", is up to your interpretation. Note, that there was also clear consensus for the following problems:

• Corrosive RfA atmosphere: The atmosphere at RfA is deeply unpleasant. This makes it so fewer candidates wish to run and also means that some members of our community don't comment/vote.
• Level of scrutiny: Many editors believe it would be unpleasant to have so much attention focused on them. This includes being indirectly a part of watchlists and editors going through your edit history with the chance that some event, possibly a relatively trivial event, becomes the focus of editor discussion for up to a week.
• Standards needed to pass keep rising: It used to be far easier to pass RfA however the standards necessary to pass have continued to rise such that only "perfect" candidates will pass now.

I respect your view, but I don't think many would agree with you. 0xDeadbeef 11:39, 26 September 2022 (UTC)

If many don't agree with me, then why were similar proposals resoundly defeated At least 17 times previously? I mean, have a go if you want to. I might even not point, laugh aggressively, and say "I told you so!" when it fails yet again. --Jayron32 17:12, 26 September 2022 (UTC)

This isn't similar to other proposals under the umbrella of admin unbundling. We are not splitting the block user right such that someone with the right can block anyone for any amount of time like admins. And unlike the vandal fighter RfC, this does not involve the ability of indeffing non-autoconfirmed editors. This proposal is for responding to clear cases of vandalism only. 0xDeadbeef 00:00, 27 September 2022 (UTC)

This proposal is for solving a problem with AIV, not "trying to dodge RFA". I would be happy to change the wording however you think appropriate so that this difference is more clear. Enterprisey (talk!) 23:15, 26 September 2022 (UTC)

Start the RfC? (2)

We should start the RfC. This proposal has gotten more than enough feedback, and we should put it out there. We’ve seen the responses from some opposers, and gotten feedback from VPIL. Not much else to do but launch it. ‡ Night Watch ω (talk) 23:13, 24 September 2022 (UTC)

I guess the writing part is mostly done. Data from 2022 would be nice (only takes a couple days on toolforge, I'll kick that off soon), and beyond that I've heard that it might be strategically wise to let a few more months go by while people randomly stumble across it, because that might build support some more. Maybe let's pick a date? I don't want to coincide with ACE or any other prominent onwiki events. Enterprisey (talk!) 23:02, 26 September 2022 (UTC)

Let's wait until after ACE and the holidays have settled down. I heard that editors are a bit busy then. Perhaps late January? I'll write it down so we don't forget. ‡ Night Watch ω (talk) 23:43, 26 September 2022 (UTC)

@The Night Watch - I have a sneaking suspicion you may have forgotten casualdejekyll 01:54, 26 August 2023 (UTC)

Thanks for this reminder. I was intending to do this a few weeks ago but forgot after I got distracted.. 0xDeadbeef→∞ (talk to me) 03:07, 26 August 2023 (UTC)

Oh man what a throwback... just requesting 48 hours starting from this comment to see if I can start the data collection run for 2022, and if I don't have any updates then feel free to start it whenever. Enterprisey (talk!) 16:24, 27 August 2023 (UTC)

Hi @Enterprisey, it's been more than 48 hours, were you intending to respond within 48 hours from that comment? 0xDeadbeef→∞ (talk to me) 12:00, 31 August 2023 (UTC)

Ha ha... yeah it seems like work just got busy again. I think it's fine with what's on there now, honestly - does anyone else think it'll be a problem if we don't have 2022? Enterprisey (talk!) 01:38, 1 September 2023 (UTC)

I don't see a problem with not having 2022 statistics, although if we start a RfC there could be people who would like to see them. IMO 2022 stats shouldn't be too different from 2021. 0xDeadbeef→∞ (talk to me) 08:30, 1 September 2023 (UTC)

So actually I had some time, so I submitted a job that'll examine edits during one year starting on 1 September 2022 and ending on 1 September 2023. We'll see how that goes. Enterprisey (talk!) 16:52, 3 September 2023 (UTC)

Update: It ran until it got to edits from the middle of october and crashed. I shall improve the code a bit and will start it again tomorrow. Enterprisey (talk!) 05:17, 5 September 2023 (UTC)

Has it been started? 0xDeadbeef→∞ (talk to me) 05:00, 9 September 2023 (UTC)

Yes, actually, just now! Logs are at https://apersonbot.toolforge.org/aiv-analysis/aiv-analysis-2023-09-09.out.txt and https://apersonbot.toolforge.org/aiv-analysis/aiv-analysis-2023-09-09.err.txt for output and errors, respectively, so you can follow along. (How to read: the "out" page may contain errors and that's OK; if the "err" page has errors then it probably died, in which case please poke me on Discord or something.) I hope I didn't add any more bugs this time... Enterprisey (talk!) 07:07, 9 September 2023 (UTC)

So that job died, but fortunately it seems to have produced 6 months worth of data. I have restarted the job, running only on the remaining 6 months. As usual the output is https://apersonbot.toolforge.org/aiv-analysis/aiv-analysis-2023-09-14.out.txt and the errors are https://apersonbot.toolforge.org/aiv-analysis/aiv-analysis-2023-09-14.err.txt. Enterprisey (talk!) 02:32, 15 September 2023 (UTC)

*sigh* and we're back again, https://apersonbot.toolforge.org/aiv-analysis/aiv-analysis-2023-09-16.out.txt and you can guess the err link by now. I don't know why it's being so troublesome, and I have limited debugging capabilities without doing a more time-consuming rewrite of the program. I hope it manages to make it a few months at least this time. Enterprisey (talk!) 06:44, 16 September 2023 (UTC)

Back once again because it crashed; see https://apersonbot.toolforge.org/aiv-analysis/aiv-analysis-2023-09-17.out.txt. You may have noticed quite a few errors from "contributions" calls in recent logs. I'd been assuming {{Ipvandal}} was being used if and only if the editor being reported was an IP address, but it turns out this hasn't been the case for many months now. I'm rerunning the job starting in February 2023 because that's when I saw an increase in the number of errors (perhaps some script had been changed). Needless to say I've removed this assumption because it was pointless in the first place. Hopefully this'll make the job crash less too - maybe MediaWiki was limiting it somehow due to all the errors? Enterprisey (talk!) 03:11, 17 September 2023 (UTC)

Probably related to this TfD, which was implemented in February. Extraordinary Writ (talk) 03:22, 17 September 2023 (UTC)

Thanks for your efforts on this. 0xDeadbeef→∞ (talk to me) 03:24, 17 September 2023 (UTC)

Thanks Extraordinary Writ for the digging and 0xDeadbeef for the encouragement. Hopefully it'll be all worth it! :) Enterprisey (talk!) 03:28, 17 September 2023 (UTC)

Alright, it's finished! I just want to make an update to the analysis script and then I'll post the analysis. The fact that the graphs extension broke is quite sad, but I'm perfectly capable of making the graphs by hand. Enterprisey (talk!) 03:01, 20 September 2023 (UTC)

The data files are up at https://apersonbot.toolforge.org/aiv-analysis/2022-09-01T00:00:00Z--2023-09-01T00:00:00Z--cases.0.json and https://apersonbot.toolforge.org/aiv-analysis/2023-02-01T00:00:00Z--2023-09-01T00:00:00Z--cases.0.json. Same schema as always (https://git.sr.ht/~enterprisey/aiv-analysis/tree/master/item/case_format.txt). They overlap starting on 2023-02-01. I'm going to solve this by removing some of the cases from the end of the earlier file, and then I'll upload the cleaned version. Enterprisey (talk!) 05:45, 20 September 2023 (UTC)

And the cleaned file has been uploaded at https://apersonbot.toolforge.org/aiv-analysis/2022-09-01T00:00:00Z--2023-02-01T00:00:00Z--cases.0.json. Enterprisey (talk!) 06:00, 20 September 2023 (UTC)

Analyzed and posted at User:Enterprisey/AIV analysis. Help requested in making graphs out of that data. Enterprisey (talk!) 06:05, 20 September 2023 (UTC)

Hm. I think the most recent batch of data makes somewhat of a weaker case for the role than data from previous years... what do you all think? Enterprisey (talk!) 06:12, 20 September 2023 (UTC)

Is it worse? I had a look at the data, and the percentage of all cases that warranted a responder block of all cases that ended up with a block remained relatively the same: Such cases were about 60% of "block" cases with 2 or more edits and about 12% of all "block" cases. (new) and That's about 59% of all cases with 2 or more edits and about 10% of all cases. (old) 0xDeadbeef→∞ (talk to me) 06:06, 14 October 2023 (UTC)

Example case

Special:Contributions/46.48.144.35. A responder would have stopped this. 0xDeadbeef→∞ (talk to me) 06:46, 27 October 2022 (UTC)

AbuseFilter blocks?

In case people haven't seen it yet: WP:VPI#Idea: Enable the AbuseFilter blocking action -- RoySmith (talk) 22:55, 29 November 2022 (UTC)

A majority of participants at the discussion seem to argue that they prefer humans to do the blocking. 0xDeadbeef→∞ (talk to me) 01:39, 30 November 2022 (UTC)

UAA consideration

Putting this here to remind myself of this, as well as proposing a similar action with WP:UAA if similarly blatant. Silikonz💬 22:07, 11 January 2023 (UTC)

Make it more useful

We indefinitely block vandalism only accounts because we assume they are under the control of a vandal, and we dish out short term blocks for IPs because IPs are often shared or reallocated. For the responder role to be useful and actually take pressure off our declining number of admins, we need them to be as good at spotting vandalism as a rollbacker or admin needs to be, and their blocks to be as long lasting as an admin would dish out. Blocking people for just an hour doesn't reduce the admin workload, and it is admins we are short of.

Rollback has long worked on the basis that if you hit Rollback on someone else's edits you are asserting those edits to be vandalism. This works well, we only rarely have to revoke rollback rights. Blatant vandalism is a bright line rule that lots of Wikipedians get. So just as it is only policy not technology that limits Rollback to blatant vandalism, I don't see a problem with a policy that restricts Responder's blocks to blatant vandalism.

Limiting the Responder's block ability to only IPs and accounts that are either not yet confirmed or not yet extended confirmed would minimise complications from this, and give admins an easy solution to arguments involving a Responder and a goodfaith newbie, if there is doubt as to whether the Responder was threatening to block the newbie, and the newbie is clearly doing good edits, you can just set the newbie as extended confirmed.

As for the criteria? I suggest that any admin can grant this to any rollbacker who has been using Rollback for a couple of months uncontentiously, and any admin can advise, revert and if necessary revoke the right from Responder's who make mistakes as to what is vandalism. ϢereSpielChequers 10:02, 20 September 2023 (UTC)

Blocking people for just an hour doesn't reduce the admin workload, and it is admins we are short of. Yeah. AFAIK, this draft started as a proposed solution to vandals making edits in rapid succession that require intervention that is not a) reverting every edit they make until an admin takes action, or b) wait until a block is issued until mass-rollbacking the edits they have made in the mean time. Both a) and b) would have created more work for people if the vandal was not blocked in time. BUT, recent data might suggest that we don't have a lot of cases like these to justify a role for a very niche, specific problem.

I personally don't see a problem with what you are suggesting, but I think the biggest argument against this idea could be that only being able to block people would resulting in blocks being issued when other types of admin actions would be more appropriate. For example, when a vandal hops to different IPs to vandalize a specific set of pages, or when a specific page attracts a lot of vandalism where page protection would be more appropriate, etc.

Also, by making it closer to the full admin toolset we are more bound to attract oppose !votes that just say "this is admin unbundling and per the previous RFCs I will oppose". I agree that ability to issue blocks for arbitrary periods would make the role many times more useful, and I think this draft was being very conservative in what is being proposed due to how the other similar proposals went. 0xDeadbeef→∞ (talk to me) 15:36, 20 September 2023 (UTC)

Another common argument would be that we should be encouraging more people to become admins instead of adding roles like this, because this could increase the requirements to becoming an admin. (by making this role another soft requirement for becoming an admin) But the other side of this argument would be that having the role and using the tools the role gives can help showcase good judgement and demonstrate that the user is trusted to be an admin, such that becoming an admin would be actually easier. 0xDeadbeef→∞ (talk to me) 15:47, 20 September 2023 (UTC)

Applying

Shouldn't we make people apply for the user right at PERM, not AN? It would make more sense to apply for a user right on the page made specifically for applying for user rights. QuicoleJR (talk) 14:07, 6 October 2023 (UTC)

RfA review

A proposal very similar to this was proposed at Wikipedia:Requests for adminship/2024 review/Phase I#Proposal 10: Unbundling 90% of blocks * Pppery * _{it has begun...} 17:21, 22 February 2024 (UTC)

I'm actually fine with calling this proposal dead. The purpose of a "responder" is very narrow, and people are just against unbundling. 0xDeadbeef→∞ (talk to me) 04:32, 25 February 2024 (UTC)

I was enthusiastic about this when it came out, but after more than three years and no progress, It's time to play the {{Failed proposal}} card. RoySmith (talk) 15:44, 25 February 2024 (UTC)